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TECHNICAL PAPER 


PRACTICES IN ADEQUATE STRUCTURAL DESIGN 


I. INTRODUCTION 

Since the Challenger accident, the focus of NASA has centered on space vehicles, their problems, 
their design, and their verification. The recurring question can be simply stated as: What constitutes 
adequate structural design and verification? Many have attempted to answer this question. Structural 
design manuals and handbooks address the subject, most very thoroughly. With all the wealth of 
material, why open it again? The Challenger accident reopened every question dealing with reliability 
and safety. As a result, the question became highly focused through the failure investigation and the 
resulting audits for return to flight. NASA and its contractors have spent the last two years redesigning 
hardware and conducting the following major audits: (1) structural, (2) fracture mechanics, (3) weld 
assessments, (4) FMEA/CILs (failure mode effects analysis/critical items list), (5) hazards, (6) DCR 
(design critical review) exercises, (7) FRRs (flight readiness reviews), and (8) PDRs (preliminary design 
reviews) and CDRs (critical design reviews) for redesigned parts. These assessments have brought many 
aspects of the question into a sharpened image. In order to see the sharper focus, however, one must 
formulate subsets of questions. Some of the questions are: 

(1) What are the roles management plays and the procedures they use? 

(2) How and to what extent are philosophy, procedures, and criteria a part of good design? 

(3) How important are methodology, codes, etc.? 

(4) What are the roles of testing? 

(5) How does documentation fit into the picture? 

(6) How do performance requirements impact design adequacy, and what is the criteria for 
determining adequacy? 

(7) What constitutes an optimum design? 

(8) What is the role of system engineering in design and verification? 

(9) What effects do operations and refurbishment requirements have on design and verification? 

(10) How does failure philosophy (fail safe, etc.) impact the process? 

The answer to these and other questions must be tied together to form a consistent, overall approach that 
will result in good, safe hardware. 



Since the 5 1-L incident, investigation results focused attention on safety of design, thus on desigr 
audits. It is appropriate that this paper begin with a definition of a design audit. An audit is a review oi 
something that has been done relative to an accepted or proven set of criteria. In many cases the establish- 
ment of these criteria is very debatable. A structural audit, for example, would challenge the design anc 
verification against the design specifications (performance) given in terms of operational lifetime, 
margins of safety, fracture mechanics, inspections [NDI (nondestructive inspection)] etc., all made rela- 
tive to standards of management, documentation, analysis, test, data bases, as-built hardware, history, 
etc. Conducting the audit is not easy since major questions have to be dealt with: 

(1) Should the review be top down or bottom up? 

(2) What are the standards goodness is judged against, is it concrete or the judgement of the 
reviewer? 

(3) How are the results (recommendations) managed: (a) short term, (b) long term, and (c) future 
projects? 

(4) Who does the reviews: (a) independent auditors, (b) design engineers, etc? 

Some oi these questions also arise during the design and verification of any system. The answers to these 
questions are different depending on the audit being conducted. 

In order to conduct the audits, a review must first be made of all requirements followed by the 
development of audit checkoff forms and questions for each discipline and each audit. As a result, trace- 
ability has to be shown from requirements to performance with the adequacy of the performance 
established from both analysis and test, as well as supporting documentation. As stated previously, many 
audits were conducted from failure mode effects analyses to weld assessments and all are interrelated and 
connected. The structure is declared safe only if all the wickets are passed or appropriate waivers with 
risk assessment (rationale) developed. 

The observations or guidelines discussed in this document are the result of NASA/industry parti- 
cipation in these audits/reviews. Through many discussions with others, their thoughts, ideas, etc., the 
author was influenced greatly in developing these ideas. It is impossible to give each credit; however, 
laboratory director, Dr. George McDonough, and Vince Verderaime, laboratory technical staff, have 
been both an inspiration and the source of many challenging thoughts. This paper will deal with these 
observations in the areas of (1) general approaches, (2) management and control, (3) analysis and test, 
(4) documentation and data basing, and (5) procedures and criteria. Mechanical disciplines alluded to 
will include: (1) stress; (2) dynamics; (3) fracture mechanics; (4) NDI; (5) quality; (6) environments, (a) 
thermal, (b) flow, and (c) vibration; (7) natural environments; (8) testing; (9) fatigue; and (10) system 
analysis. Other disciplines are similarly scrutinized but are outside the scope of this discussion. The basic 
principles are applicable, however, to all disciplines and areas. 
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II. GENERAL CONSIDERATIONS 


This paper is written basically from the engineering point of view; however, no discussion of the 
engineering process is complete without a brief reference to how a project evolves and the role of 
engineering with management in this early evolution. 

After a national commitment for a space system, spacecraft, or space mission has been identified 
and top level (level I) requirements and goals are defined, the proposed project is studied through a phase 
A feasibility effort to develop significant operational, developmental, and programmatical characteris- 
tics, and to determine: 

(1) The performance required to accomplish the mission. 

(2) Time required to develop and operate the system. 

(3) Funding necessary for all phases. 

Level I is the overall performance requirements; level II is the basic system requirements; level III 
is the spacecraft, etc., element requirements; and level IV, if it exists, is the next level down. 

The three keys to the triangle of project management are: performance, schedule, and costs (Fig. 
1). The test of how well the key fits is minimizing the risks and consequences involved. Is a new tech- 
nology involved? Will the risk for developing it result in untimely completion and cost overruns? At this 
point in time, phase A satisfactorily establishes feasibility with acceptable risks. The new technology for 
Space Shuttle was the orbiter tiles. No large space project has survived initial concept where more than 
one major new technology was required. Improving existing technologies does not count. 

The project then proceeds to a phase B study to develop level II and III requirements, to propose 
design options for satisfying requirements, and to perform trade studies for selecting the optimum design. 
The resulting “request for proposal” (RFP) must identify and address all significant risks that might alfect 
performance, schedule, and costs. The role of engineering support to the project is most critical in this 
phase for identifying risks, tasks, sensitivities, etc., that affect cost, schedules, and performance. 

Requirements identified for the project and in the RFP must be stated void of solution so that 
options are left open. For example, do not specify a viewing window and rule out the use of a TV 
canmera which may be more versatile and cost effective. The requirement should be the capability to 
observe a particular event. Options can then be evaluated on reliability, performance, consequences, 
cost, etc., and the optimum selected. 

These trades should be a combined exercise of project management and engineering. The result is 
the final configuration selection for phase C and D (design and development), stating clearly an estima- 
tion of the significant spacecraft configuration characteristics and special resources necessary through 
operations. 
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COST 



Configuration selection at the completion of phase B is a critical step. All pertinent information 
required for phase C/D has been developed during this phase and now must be processed into a 
comprehensive RFP. This requires a team effort including legal, project, contracts and procurement, and 
engineering. Engineering is responsible for performance requirements, subsystems definition, data base, 
and verification requirements. The RFP is followed by a Source Evaluation Board (SEB) where the con- 
tractors proposals are evaluated. Engineering, as members of this board, evaluate the replies relative to 
compliance with the RFP and identify the “extra-plus” contributions or lack thereof. They assess the test 
program, articles required and flow, and facility capability. The result is selection of the contractor and 
initiation of the project. The process and principles which are involved to some extent during phases A 
and B, and are controlling during phase C/D, constitute the body of the report. 

How to find your way through the design and verification maze of a project is a puzzling question 
illustrated by the maze in Figure 2. What the major blocks are, how each is cleared, and how each is 
integrated to form the whole are the major questions represented. In the sections that follow, the assump- 
tion is made that the standard engineering approach is used, i.e., (1) define the problem, (2) conduct 
simplified response and sensitivity analyses to establish understanding and limits, (3) perform detailed 
analyses and test to characterize system, and (4) validate the characterization of the system. In order to 
scientifically interrogate, we have to do so from a point of view. Our expectations become the spectacles 
in front of the eyes that influence what we see. Therefore, in order to deal with the issues which follow, it 
is important to establish an overall concept, philosophy, or approach. That viewpoint is one which sees 
from each prospective the whole as well as the parts, how they interact, and everything in between. The 
basis for this viewpoint is system engineering, or just system analysis and testing. All interactions, both 
interdisciplinary and interphase, from concept to operations, must be tied together, including failure 
criteria, such as fail safe, fail safe fail operations, etc. In all likelihood, more failures have been caused 
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How to find your way through the 
Design and Verification of Structural Systems 



Figure 2. The maze. 


from lack of systems engineering than any other one cause. Many illustrations could be given. The first 
of my experience occurred on the Redstone military rocket. The vehicle was lying in its horizontal cradle 
undergoing checkout of the control system. A bending mode was excited when the gyro pickup poten- 
tiometer (composed of wound coil and pickup arm) jumped from one wire to the other creating step 
signal changes to the control system. This signal moved the jet vanes (control force source) which further 
inertially excited the mode creating a closed-loop structural control interaction problem maintaining the 
oscillation. The noise of the oscillation was very loud and scary, impressing everyone that so much 
energy could be present in just the inertial part of the control system. “It only hurts at resonance” was 
dramatically illustrated. Since this was a small amplitude, nonlinear oscillation, it limit cycled and no 
problems occurred. The fix was simple, an analog filter was used to break the loop by filtering out the 
bending mode frequency component of the signal. 

System analysis, system test, and system integration must be accomplished. Paramount in this 
viewpoint are sensitivity investigations that identify key parameters and predict interactions. This can 
and should be approached from both bottoms-up and tops-down considerations. It should be emphasized 
that from wherever the process is viewed, the total picture must be kept in focus, understood, and worked 
at all levels and interfaces. The pyramid view (Fig. 3) is valid for all the major blocks in the maze. 

Obviously, from the top down, each level contains greater and greater details while fitting into the 
whole. Management as well as analysis must fit into this concept. In making this statement it is not 
implied that a very formal authority line is enforced, but only that some management or leadership should 
exist at each level starting with project management down to the individual engineer, technician, etc. As 
discussed later this, in general, means the acceptance of the responsibility by the man doing the job, 
including communication, etc. The management approaches in books by Drucker and the latest by Peters 
and others [1, 2, 3, 8, 11, 12, 44 through 51] adequately set the tone of what is implied by the term 
management. This raises a basic problem in terms of communication between the levels, the source of 
the known CEIs (contract end items), etc. It should be clear that there is also a flow between the various 
major areas of emphasis. This flow is both vertical and horizontal. In general, more is required horizon- 
tally than vertically. The complexity of the interaction and exchange is hard to depict; however, analysis, 
test, management, and documentation must flow between disciplines and organization levels. To insure 
that the system focus and approach is applied, very basic principles must be applied. The following is a 
discussion of the top 12 principles. 

1. Interfaces are Compatible and Well Defined 

The interfaces must be compatible and well defined. This means that when crossing from one 
level to another, or between categories, some form of pattern recognition, hence symbols, must be 
developed and established so that only the essentials (maybe special symbols) and all aspects of the 
details will be viewed. The development of these patterns/symbols (recognition approaches) is key to all 
the various aspects of the design verification process. This problem is complex enough if everything is 
contained in one organization; however, for aerospace in general, the multiplicity of organizations 
involved in providing parts, subsystems, elements, and the verification analysis and test is very large. 
The ability to provide these symbols, establish communications, and to insure compatibility is a major 
problem in assuring adequacy of structural design. 
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TOPS DOWN 



Figure 3. Viewpoint. 


BOTTOMS UP 


2. People Are The Prime Resource 

For the approach to work, it must be recognized that people are the prime resource for accom- 
plishing the tasks. Other resources should be aids for the human. This will be discussed more under 
management; however, it is the fulcrum about which all else pivots. This points to the next big principle. 

3. Analysis and Test are Limited 

All simulations, models, symbols, patterns, etc., whether dealing with analysis, test, 
management, etc., are just that, models which are not complete (limited) and are not exact representa- 
tions of reality but are mathematical or physical representations or symbols with various assumptions of 
these facts. In the book Mathematics for Dynamic Modeling, Edward Beltran says, 

“The essence of modeling, as we see it, is that one begins with a nontrivial work problem 
about the world around us. We then grapple with the not always obvious problem of how 
it can be posed as a mathematical question. Emphasis is on the evolution of a roughly con- 
ceived idea into a more abstract but manageable form in which inessentials have been 
eliminated. One of the lessons learned is that there is no best model, only better ones. The 
model is only a suggestive metaphor, a fiction about the messy and unwieldy observa- 
tions of the real world. In order for it to be persuasive, to convey a sense of credibility, it 
is important that it not be too complicated and that the assumptions that are made be clear- 
ly in evidence. In short, the model must be simple, transparent, and verifiable.” [53] 

This principle must be fully understood so that everything is being constantly challenged for applic- 
ability. The major problem we deal with is how this less-than-reality information is meshed together to 
get verified, reliable systems. Obviously, this can only be done in some probabilistic sense. As is illus- 
trated in Figure 4, this is the goal of a system. If it is a space system, then the goal is reliable operation 
with adequate safety margins that meet the performance requirements goals. Obviously, robust statistical 
approaches must fundamentally apply to insure that all outliers are understood and accepted. This raises 
the next major principle. 

4. Performance Requirements Drive Design 

The system performance requirements determine the design, technologies, penetrations, etc., 
necessary to meet the goal. Performance requirements are always broad in scope, encompassing not only 
the response but also all characteristics from design through operations. For example, if the payload-to- 
orbit performance is good, but the payload must be operated only in very restricted conditions and with 
great effort, the net performance may be poor. The higher the performance, by definition, the greater the 
sensitivity of the design to uncertainties. Uncertainties exist in all the areas of design: materials proper- 
ties, environments, analysis, testing, manufacturing, etc. If one thinks about this deep enough, a generic 
curve can be constructed of sensitivity versus performance (Fig. 5). 

Designs in the flat portion of the curve basically can be dealt with in a linear fashion. As the 
design moves out on the curve into the steeper slopes, nonlinear analysis is implied. In the first case, the 
design is inherently conservative and easily predicted, since superposition works and the nonlinearities 
not used to gain margin are still present and do add to the margins. (Nonlinearities in general are conserv- 
ative.) In the latter case (high performance design), use must be made of the nonlinearities in order to 
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Figure 4. The steps to the goal. 



Figure 5. Sensitivity versus performance. 


meet design margins criteria. It should be pointed out that nonlinearities are not easily predicted or 
analyzed. They are certainly sensitive to unknowns and changes. If the performance requirements are 
such that the design is inherently in this region, then great care and accuracy must be taken to develop 
data bases, define environments, and perform analyses, etc. Manufacturing, nondestructive investiga- 
tion, quality control, and acceptence criteria parameters must be enhanced. If, however, one designs for 
robustness, the lower curve exists, providing margin at the performance index. For example, the design 
option limits are (1) achieve robustness at a large increase in weight using more volume, pressure, etc., 
or (2) minimize weight at all cost, achieving performance through sophistication, including exotic 
materials, etc. In option 1 (assume a launch vehicle), the added weight and size, although achieving 
robustness on the surface, increases hardware cost. Option 2 bypasses this kind of cost increase but adds 
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cost due to the higher accuracy requirements, etc. The optimum lies somewhere between the two 
extremes. The curve can also be shifted to the right through data acquisition and increased knowledge, in 
many cases a desirable approach (technology advancement). At the onset and periodically throughout the 
program, sensitivity studies must be made to determine where the design rests, what parameters should 
be made robust, and what the real optimum is considering all factors. Other curves or data illustrate this 
same type of information or sensitivity. For example, the S-N curve for a structure at or near yield shows 
the same phenomenon (Fig. 6). Operating at the flat portion of the curve creates a large sensitivity of life 
to small changes in alternating stress. A 5 percent increase in alternating stress can reduce life up to two 
orders of magnitude. 



In this case, the part usually has limited life, small oscillating strains, and high frequencies which 
lead to short lives. Implied also is the dependence on high cycle fracture mechanics as well as plastic 
(nonlinear) low cycle fracture control, thus, NDI requirements become very stringent. 

Three examples from the Space Shuttle program will be given to illustrate the reality of the 
performance/sensitivity principles. Numerous examples exist, however, those chosen should be suf- 
ficient to illustrate the principle: (1) pre- and liftoff loads, (2) max Q loads, and (3) engine 4000 Hz. 
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a. Pre-Liftoff and Liftoff Loads 


The Space Shuttle on the pad and at liftoff is a multi-body dynamic system. This is a very 
complex system consisting of five Shuttle elements [payload, orbiter, external tank (ET), two solid 
rocket boosters (SRBs), and the mobile launcher pad (MLP)]. The Shuttle is attached to the MLP through 
four posts on each SRB. All external loads and the vehicle weight are reacted through these eight elastic 
posts. The sequence for liftoff requires that the SSMEs be up to full power before igniting the SRBs and 
lifting off. This thrust force bends the vehicle in two ways, storing energy through deforming the (elastic) 
structure. The vehicle bends in the pitch plane deflecting the nose of the SRBs approximately 2 ft. This 
energy is stored in struts, the SRM/MLP posts, and basic skin and structure at the strut attach points. The 
second bending occurs due to the lateral component of the thrust driving the orbiter and tank between the 
SRBs, rolling the SRBs in a gear train fashion. Two other parameters affect this stored energy: 
(1) vehicle weight and (2) cryogenic shrinkage. Before propellant loading, the vehicle is misaligned at 
the aft SRB-to-ET struts by 7 deg (struts not perpendicular to the center of the vehicle). With propellant 
loading, the tank shrinks bringing the struts to the perpendicular condition, storing energy (aft tank ring 
and bulkhead) in the tank. Figure 7 shows the vehicle side view on the pad, while Figure 8 shows the 
stored bending moment as the SRBs are rolled in the gear train mode. Typical elastic connections are 
shown as springs instead of actual hardware. To reduce loads at liftoff, the SRBs are ignited at the 
minimum Y bending moment point. What parameters affect the vehicle loads and how sensitive the loads 
are to these parameters are the main concerns. Key parameters are (1) the definition of the elastic 
characteristics of all structures, including the MLP; (2) SSME thrust; (3) SRB thrust rise rate and thrust; 
(4) winds; (5) payloads; (6) sequencing; and (7) overpressure. Because of dynamic tuning, the 
unsymmetric load paths, and point loads, the vehicle response (loads) is very sensitive to small changes 
in parameters. Plus or minus 20 percent in loads is common with model updates. Larger changes, 50 
percent, can occur for certain parameter changes that affect payload loads. References 19 and 20 contain 
many examples of these effects, however, only one is shown. Space telescope ascent loads increased 
significantly due to small shifts in models to account for design changes, etc. Figure 9 shows the result- 
ing load changes between three loads cycles compared to the original design estimation. Notice that the 
vector load of the secondary mirror increased from 6 g to 13 g, basically due to model updates. 

b. Max “Q” Orbiter Wing Loads 

The first Shuttle flight showed an aerodynamic moment different from prediction, causing the 
vehicle to loft more than expected. The cause was an aerodynamic distribution shift (total force was 
approximately correct) due to inability to correctly simulate plume effects in the wind tunnel tests. The 
small shift in aerodynamic distribution had a major effect on the wing load, and hence its structural cap- 
ability. Figure 10 shows the original “qa” capability of the wind using the predicted aerodynamic disti ibu- 
tion. Shown on the same figure is the current best understood wing capability after beefing up structure in 
the wing’s leading edge. The wing root, etc., because of inaccessibility, was not beefed up to solve the 
total problem. It should be pointed out, however, that to fix the total wing problem would also involve 
changes to the fuselage. In order to fly safely, the trajectory shape had to be changed to fly within the 
revised “qa” boundaries shown in Figure 10. This does not come free. The cost is a several-thousand- 
pound loss of payload capability. This high sensitivity of trajectory shape to loads and performance illus- 
trates clearly the point being made. As a result of this effect, all Shuttle flights are specifically tailored 
with stringent day-of-launch commit criteria. Details of this total area can be obtained from JSC/ 
Rockwell. More information on the interactions is contained in Reference 20. 
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COMPONENT DIR 

MAXIMUM ACCELERATION (G’s) 
LIFTOFF LOADS 

DESIGN 

VALUE 

P.L.C. 

I.L.C. 

C.D.R. 

PRIMARY 

X 

3.7 

3.1 

3.5 

4.5 

MIRROR 

Y 

2.4 

1.1 

1.2 

0.9 


Z 

3.7 

2.6 

2.0 

3.2 

SECONDARY 

X 

3.8 

'3.1 

3.4 

4.5 

MIRROR 

Y 

3.5 

2.3 

2.6 

2.3 


Z 

6.7 

5.0 

3.3 

12.9 


P.L.C. = PRELIMINARY LOAD CYCLE, USED 5.4 SHUTTLE DATA 

I.L.C. = INTERMEDIATE LOAD CYCLE, USED 5.7 SHUTTLE DATA 

C.D.R. = CRITICAL DESIGN REVIEW LOAD CYCLE, USED 5.8 SHUTTLE DATA 
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RANGE 
OV-99/1 02 
FLIGHTS 


MIN 5.4 

DESIGN FLIGHT 
ENVELOPE 


MACH NUMBER 

Figure 10. Ascent flight envelope limits. 


c. SSME 4000 Hz Oscillation 

The SSME is a very high performance system that, on the flow side, has a very high dynamic 
pressure environment. As a result, various structures are very sensitive to flow and acoustic/structural 
interaction problems. Figures 1 1 and 12 show the lox flow system near and into the injector. The lox inlet 
has a two blade splitter in order to create a more uniform lox flow distribution into the lox dome (Fig. 1 3). 
Any type vane protrusion into this high flow environment is susceptible to flow-induced oscillations and, 
thus, fatigue failure. This has occurred on the inlet splitter. Three engine units have had cracked splitters. 
These fatigue cracks are believed, based on analysis and test, to be caused by vortex shedding off the 
vane trailing edge occurring at the vane natural frequency at 4000 Hz. In addition to the three splitters 
with cracks, several other units have shown the 4000 Hz phenomenon, but at a lower level, without 
cracks. The amplitude determines the alternating stresses, hence, life. Figure 14 shows a spectrum of 
an engine with and without the 4000 Hz buzz. Notice the narrowband sharpness of the tuning. The interest- 
ing part of the story is that 10 percent of the engines buzz, the others do not at any time in their test 
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Figure 1 1 . 4000 Hz vibration anomaly main injector. 




Figure 12. 4000 Hz vibration phenomenon. 






Figure 14. Spectrum of gimbal bearing accelerometer. 

history. There does appear to be some correlation of buzz amplitude with power level; however, the fre- 
quency of the oscillation is independent of power level. The buzz cause has to be due to small manufac- 
turing differences in the bluntness of the vane trailing edge and possibly small vane angle/offset dif- 
ferences or slight modal shifts. There is one proposal that says the variation in shell thickness at the nose 
of the vanes changes the tuning, etc., causing the vane oscillation to tune and amplify. The problem has 
been fixed by sharpening the vane trailing edge and scalloping the leading edge to allow more flow area 
between the two vanes. Engine 2025 buzzed around 100 gs before the fix and had no discrete 4000 Hz 
component after the fix. The message is clear, high performance systems are very sensitive to small 
changes, whether in manufacturing or environments, many times leading to failure or strict operational 
requirements. 


As stated previously, for these high sensitivity regimes, extreme care must be exercised in deter- 
mining characteristics and operational criteria. As a result of these high tech requirements, the reliability 
of the system requires greatly increased technology for testing, analysis, manufacturing, quality, etc. 
Operations also, in general, become more costly with tighter constraints and loss of flexibility, along 
with design and development phases. Obviously, there comes a point where the total system is more 
optimum at points where structural (or other) performance is traded for weight, fuel, etc. Also, more 
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emphasis on optimization selection criteria is implied for configuration selection (based on many 
parameters, not just weight). Does this mean that high tech design is not pursued? In no way; however, 
the implication is clear that big increases in knowledge (technology) are required, with tighter accept- 
ance controls if the design is to be adequate. This means that judging a design’s adequacy requires under- 
standing the operation point on the sensitivity curve. Figure 15 is an attempt to flow these optimization 
trades together. Notice that the process is iterative and not a one-time effort. 



Figure 15. Design and verification. 

5. Design for Robustness and Growth 

Design for robustness and growth is key. Robustness achieves overall performance, usually at the 
expense of weight, but with reduced sensitivity to errors and unknowns. Growth potential provides flexi- 
bility allowing for mission changes as data changes (Fig. 15). 

6. Configuration Complexity Determines Penetration 

Just as important is understanding the configuration complexity. It should be pointed out that in 
many cases the attempt to solve one problem, even through simplicity, can create complexity in another. 
Back to the system focus. This complexity is evident in many areas. Two will be discussed: (1) dynamics 
and (2) static load paths. 

(1) Dynamic systems are fairly predictable if they are basically a single body without extreme 
geometric ratios. If the configuration is composed of several separate bodies connected by links, etc., the 
characteristics are those of a redundant structure and become more predictable and sensitive. The 
bodies can dynamically tune, greatly amplifying the response and reducing prediction accuracy. A more 
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unsymmetrical configuration produces a more complex problem (see discussion on Shuttle liftoff loads). 
Some argument can be made, however, that the structural damping should be greater. This helps out but 
does not solve the problem. The lower the damping, the greater the unpredictability of the dynamic tun- 
ing. It is clear that these systems become more susceptible to environnment coupling such as flow- 
induced oscillations. Reference 20 addresses the history and classes of problems that have their roots in 
complex dynamic configurations. 

(2) Static load paths are in the same category. The simpler the load path, the greater the predict- 
ability; the more complex, the less predictable. Unsymmetries worsen the situation by loading both in 
bending and shear, coupling everything together. These complexities produce stress concentrations, 
quality control problems, and non-plane stress fields, driving requirements toward more detailed analysis 
codes, testing, etc., to properly characterize the system. 

Configuration complexity is obviously a driver in determining adequate design. Flags to look for 
and work thoroughly involve symmetry versus nonsymmetry, multi-bodies, load paths, etc. Another key 
flag deals with joints, whether they are welds, bolts, connectors, or fasteners. Structure must be 
assembled with joints. One can minimize the system complexity by appropriate selection. Stress con- 
centrations are another flag. They should be reduced as much as possible, otherwise controlled by proper 
design. 

7. Philosophy 

Determining proper design and verification philosophy entails several major principles, for 
example, design for high performance, minimum margins, or large margins to cover breakdown in 
quality control, uncertainties in environments, etc. Designing for minimum margins places a large burden 
on analysis, test, manufacturing, quality control, NDI, etc., in order to have a safe system. A quality, 
high performing, realistic system can always be achieved but with a burden. The system is always ready 
for failure with any breakdown in control and understanding, and is less amenable to performance 
upgrading. Designing for flexibility in operations and increased performance is always a worthy phil- 
osophy since most systems will require growth even if not forecast. Other approaches include such things 
as (1) design for versus assessment for fracture mechanics, (2) failure considerations, (3) reuse versus 
throw-away, (4) plan for destructive hardware evaluation, (5) design for factors on endurance limit, and 
(6) use of FMEA to establish inspections, etc. If, for example, the philosophy and criteria are to 
implement a fracture control plan as an integral part of the design requirements, then, the design must 
include this philosophy. Fracture control can only be implemented partially if the design originally did 
not consider it. Several factors come into play: material selection, weld location, inspection, etc. The 
same type considerations are involved with other philosophical design options. Many other philosophical 
principles exist and will crop up throughout the remainder of the report. The next principle is mandatory 
in all design areas. 

8. Bracketing Hand Analysis is Key to Understanding 

One of the most important general principles is to make simplified hand analyses to understand 
the phenomenon and guide all more indepth computer evaluations. These should include free body 
diagrams and flow schematics to provide visualization. A fundamental part of this approach is the deter- 
mination of the extreme or limiting cases. By establishing the physical understanding of a problem and its 
bounds, greater insight and more efficiency are established. Computational approaches and testing have 
become so sophisticated that without this approach gross errors, hence faulty design, occur. 
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9. Statistical Significance Determines Design Adequacy 

A principle that cuts across all facets of the process states that all characteristics should be stated 
from both a deterministic and a statistical viewpoint. In the final analysis, these deterministic limits with 
some reasonable statistical statement are all that can be relied on. 

The statistical or probabilistic detertermination must consider all known variations of parameters. 
These variations must include environments, models, hardware, build tolerances, materials characteris- 
tics, etc. , as well as safety factors or other built-in factors so that the statistical statement incorporates all 
known effects and the unknown factors. There are many techniques for conducting and making these 
determinations for linear systems. If nonlinear determinations must be used, the assessment is greatly 
expanded, with very limited availability of tools. For example, nonlinear Monte Carlo analysis, one tech- 
nique available, is very costly in terms of computer time. 

The deterministic statement is made by running a discrete analysis where one or several 
parameters are perturbed to the envelope limit. These analyses are extremely conservative but allow 
bracketing of the system. In general, a design would not be made to these extremes. Their use is for 
understanding and setting limits. 

10. The Sum of Parts is Not Equal to the Whole 

All the previous principles point to the next general principle to be discussed: the sum of the parts 
is not equal to the whole. Or said differently, a part or component responds differently when it is separate 
than it does when it is a part of the whole. As a result, we must understand interaction and sensitivities to 
provide the proper design. Verification becomes even more complex in that it must account for these 
extremes, including failures and their redundant paths, etc. This means that a system as well as an 
individualistic approach has to be developed for analysis, testing, etc., as well as management. The 
Jupiter was a classical example of control and structural coupling and how to solve the problem through 
the elimination of red tape. The step rate of the pitch command of the Jupiter was in synchronous with the 
liquid oxygen first propellant slosh mode which was unstable, as confirmed by flight guidance and con- 
trol data evaluation. The result was a saturated control system and loss of vehicle and prestige. Analytical 
and empirical models of propellant sloshing were in their infancy. This meant that a solution had to be 
found quickly and verified in order to successfully launch the next vehicle. Scale model slosh tests were 
started without all the detailed test readiness reviews (TRRs), test plans, etc. Many approaches were 
proposed and tested. The one chosen was the so-called “beer cans” [20] where long perforated cylinders 
with buoyancy spheres were floated near the surface. The verification test was made by placing an actual 
tank filled with water on a railroad car and bumping it against the line stop. This means of excitation 
showed qualitatively the difference between no fix and the fix. The next flight was flown successfully as 
planned using the beer cans and a changed step rate pitch command. Detailed analysis and testing 
followed after the flight leading to the use of baffles instead of beer cans as an operational approach. As a 
result, simplified slosh models were developed for control analysis which are still valid today. A phil- 
osophy was instituted that said sloshing would be damped using baffles to isolate sloshing from the con- 
trol system and make the baffles an integral part of the structure, saving weight. 

The previous 10 principles have dwelt essentially on the engineering side although they are 
inherent in project management. The next and final two principles shift gears somewhat with the 
emphasis on project and industry side of hardware. 
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11. Proper Relationship Between Project Management and Science and Engineering is 
Mandatory 

The end goal of a project is a safe, reliably efficient product whether it is a space vehicle, its 
elements, or an orbiting space system, etc. To meet this goal, it is mandatory that the roles and missions, 
controls, etc., between project and science and engineering be clearly defined and understood. The phil- 
osophy of how this pie is cut varies from project to project, agency to agency, and contractor to con- 
tractor. There is no black and white answer. For example, can engineering override project or does 
project make the final decision? How are cost and schedules used as both management tools and control 
of the product? In other words, does engineering or schedule determine the design? Cost and schedules 
are excellent tools yet many examples exist where inferior products resulted from over-emphasis of their 
role. Clearly this definition makes the difference between adequacy and inadequacy. As shown on Figure 
15, the concept/performance requirements traced through to the design verification involve project and 
engineering even to the selection of the original goal, mission, or product. A proper relationship between 
project and engineering is the secret to good hardware. Since this is properly under management, further 
discussion is contained in that section. 

12. Clearly Define the Roles and Mission Between Government and Contractor 

Many approaches/philosophies are used to define the working relationship between government 
and contractors. They have ranged from the stance where government was the designer/integrator with 
industry playing the role of special support (subcontractor) to the government defining the performance 
characteristics and industry designing, manufacturing, and verifying the product. Whichever of the many 
possible roles between these two extremes is chosen, it is clear that this line must be clearly drawn. 
Otherwise confusion exists, costs skyrocket, and a poor product can result. 

This brings us back to the pyramid used earlier and leads us to attempt to apply these and other 
principles to the areas necessary to adequate design and verification. These will be discussed in subse- 
quent sections. 

A set of general controlling principles has been proposed. These are listed in the summary in out- 
line form. 


III. MANAGEMENT 


Management, in conjunction with sound engineering, is the pivotal element of structural 
design. It becomes decisive at all levels adding the final edge between adequacy and inadequacy. In 
general, aerospace management can be broken out into the areas of project, engineering, and corporate 
(overall organization). Further complicating this structure is the relationship between government, 
private contractors, and subcontractors (Fig. 16). These complex interactions raise at least three 
fundamental questions: 

( 1 ) What is the role of science and engineering versus the role of project? 

(2) What is the role of government with respect to industry in delivering a product? 
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(3) What information/documentation, etc., should be required between government and con- 
tractors and prime contractors and their subcontractors? 

There is no simple, black and white answer to these questions; nevertheless, they must be dealt with if 
adequate design is to occur. All my experience has been from the engineering side, therefore, the discus- 
sion of these questions will obviously have that flavor. Also, in dealing with these questions, it is 
assumed that a goal, mission, or product has been agreed upon. Essentially, the starting place is pre- 
liminary design. 


A. Roles of Project, Science, and Engineering 

The general principle stated earlier, made mandatory that a clear, definitive statement of the roles 
between project, science, and engineering be made. This is obviously a management task that must be 
made at the corporate level with full involvement or definition by both project and engineering. The 
respective organizations and the project complexity mission, etc., help guide the decision. There are 
several options available. 

From the engineering viewpoint, the agency must determine, before going into a C/D contract, 
the extent of technical support required by the civil service. For very large and long term projects, many 
changes may be anticipated before end item delivery and therefore some technical civil service analysis 
and reviews are required continuously. The level and extent of documentation necessary could be 
exhaustive or just include areas of known high risk as a minimum. If project management is unwilling to 
commit a technical civil service level equal to 7 to 10 percent of the contractors’ engineering staff, then 
contracting for extensive documentation is wasteful - there will not be enough civil service to review it 
intelligently. However, all analysis performed by the contract is government entitled and must be 
deferred up to three years after the end item is delivered. The format, content, and cost will be negotiated 
if and when required. This is a very important consideration and it controls the car loads of paper to be 
processed by the government and can cause costs to sky rocket. 

To better understand the need for civil service technical support and contracted documentation, 
we must understand the type contracts requiring it. When projects are contracted to develop and deliver 
an end item, the contractor is responsible for all engineering analysis and it would seem that documenta- 
tion of analysis is not required for civil service technical reviews. In fact, contractors may even prefer no 
civil service technical interference. Since technical changes to the existing contract are frequent 
occurrences on large, complex projects, the civil service must make an independent judgement based on 
analysis on whether or not to accept and pay for this change. Rather than initiating an independent analy- 
sis, a less manpower intensive approach is to review the contractors’ documents for assumptions, analyti- 
cal errors, oversights, and margins. This simple condition unfolds two important and costly efforts: (1) 
a comprehensive set of documents and data must be delivered to the agency as developed; and (2) the civil 
service analysis and reviews must be current with the contractors’ activities; otherwise, decisions for 
accepting a change would be horribly delayed contributing to schedule losses and overruns. An equally 
important function the engineer serves the project manager is that in possessing the contractor analytical 
documentation, the civil service can perform timely assessment of critical and risk areas for accuracy and 
choose to perform independent analysis when indicated. Contractor discrepancies may then be brought to 
immediate attention for early resolution. 
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In NASA, one model that has been used successfully works around the following philosophy. 
Science and engineering is a technical recommending body not concerning (over statement) itself with 
cost and schedules, providing the engineering data recommendations and risks; whereas, project is the 
decision-making body using these recommendations. The project also manages the manufacturing, cost, 
schedules, etc. This allows engineering to make a more thorough technical assessment without burden of 
other concerns. If this approach is to work, then project has to be keenly attuned to engineering, constant- 
ly seeking them out, providing the resources, and changing cost and schedules if necessary to get a good 
product. Many examples exist where project would not buy into sound engineering recommendations, 
living to regret the decision when future test or operations bore out the engineering position. In deference 
to my good friends in project who have made these decisions with probably just programmatic cause, 
and, because engineering makes wrong decisions also, only one illustration will be cited. 

The Hubble Space Telescope program started out as a program totally controlled by the project. 
Project management would be responsible for both engineering and hardware integration. The con- 
tractors and government engineering would interface through project. Documentation provided by 
industry would be centrally located with very limited informal exchange between contractors and govern- 
ment engineers. As the program developed under this approach, critical technical, cost, and schedule 
problems developed. In order to solve the issues, both technical and hardware, it became necessary to 
form joint project and engineering government teams at each prime contractor plant. This team approach 
was in place for a least one year. After dissolving the formal teams, project and engineering have con- 
tinued to work very closely with an open and informal exchange between all involved. Also, as a part of 
the early corrective actions, panels or technical working groups between government and industry were 
organized, enhancing the information exchange and communications. It is clear from this experience that 
for very complex technical systems pushing the state-of-the-art, projects must be operated differently 
from basic state-of-the-art projects. The approach chosen for project/engineering interfaces must con- 
sider many factors such as industry complexity, technical complexity, program complexity, etc. As was 
illustrated by space telescope, the involvement of stringent science requirements in conjunction with the 
resulting technical/hardware and operations complexity creates a very complex and demanding integra- 
tion management situation. In general, for any project the integration tasks are viewed only from the 
hardware viewpoint such as fit or dimension criteria, etc. In reality, as discussed earlier, the systems 
viewpoint must concentrate also in engineering, simulating all interacting disciplines, subsystems, etc. 
Project’s role in balancing between cost, schedules, and performance must include constantly dealing 
with risks. Risks become the criteria through which decisions are reached. The other prime tasks of 
project deal with manufacturing and delivery of quality hardware. Obviously, project must be in a con- 
stant act of balancing between these various complex goals. The other extreme arises when project takes 
the full responsibility using engineering only when they see the need, setting the tasks, priorities, etc. 

Regardless of the roles chosen for each, it is clear that project and engineering must be integrated 
into a team approach which properly trades between requirements, performance, cost, and schedules 
using risks as one of the criteria for decision making. 

B. Roles of Government and Industry in Adequate Design 

Just as important as the roles definition between project and engineering is the roles between 
government and industry. Two extremes are: (1) government provides a contract with performance 
requirements clearly stipulated; the contractor designs, engineers, manufactures, and delivers the 
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hardware verified to meet the requirements; the only interactions are periodic status reviews; delivered 
documentation mainly centers around operations and maintenance; and (2) the government designs and 
engineers and industry manufactures the hardware under government surveillance and control; the con- 
tractor provides no warranty except engineering responsibility only from the manufacturing standpoint; 
the government provides all drawings, specifications, etc. In between is a third and probably the most 
common NASA approach. (3) the government provides the requirements and various levels of surveil- 
lance in all areas through reviews, parallel engineering penetration of critical problems, and testing. The 
contractor is prime for design, engineering, drawings, manufacturing, testing, verification, etc. This is 
essentially a team effort where industry provides the bulk of the manpower, etc. On high-tech programs it 
allows for efficient changes, understanding, etc. From initiation, project/management has to provide the 
resources for the extra government involvement. It is more costly but can lead and should lead to a better 
product. 

In summary, how a project is managed, controlled, etc., determines the output. Since 
management and control are inherent in all areas of structural design, verification, and operations, it must 
be first and include not only people but all resources, criteria, procedures, requirements, reviews, etc. 
Figures 2, 3, and 17 show how engineering management cuts across, or is inherent in, all aspects of the 
process. 

I he repiesentation does not imply the lack of level of autonomy in each structured organization 
level nor, as discussed earlier, that it is a highly dictatorial fine line of authority but that it must flow up 
and down and be integrated with the responsibility incurred by the individual doing the work. This does 
not rule out the use of skunk works, ad hoc groups, teams, or any other means that bring out the crea- 
tivity, innovation, etc., of all involved. The implication is merely that management or guidance is 
involved at all levels. Observing high level management reviews for many years, one conclusion stands 
out: the person where the rubber meets the road is the source of the judgement of the rightness or wrong- 
ness of the system. All else is wordsmithing and paper mill traceability. The latter being emphasized at 
the expense of the foimer. What I am trying to say is this: traceability control, reviews, etc., are neces- 
sary and very important, but should never get in the way of engineering. In particular, the discussion, 
judgement, innovation, assumptions, etc., that take place at all levels are the ingredients that determine 
design goodness. The only real resource we have to tap and motivate is the human engineering exhibited 
in the diverse personalities in the organizations. Management must recognize where the power is and put 
its emphasis on the major resource - People. All else is tools for making him more efficient. 

1. People 


Saying this means that the first and foremost task of management and control is leading people, 
the prime resource. I learned a very valuable lesson in this regard many years ago while coaching a 
basketball team. The game belongs to the players, the coach is only a leader. The team that wins is a team 
where all the players and all support personnel have accepted the challenge to win and have taken the 
responsibility to keep physically and mentally fit, shaipen their skills, concentrate on team plan, and 
work for the good of all. The same is true of engineering a complex system. Individual responsibility and 
growth (internalized acceptance of the challenge, the objectives) at every level and job, working for a 
common goal is the secret. Managers must recognize that their task is of leadership in these areas and 
they are not directors. Again, in the final analysis, the game belongs to the players. Even planning must 
be accomplished by all at every level. 
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2. Vision 


One of the priority tasks of management and a fundamental part of leading people at any level is 
providing or establishing vision through living it. The vision provides meaning and focus to an organiza- 
tion. In the book of Proverbs it says “where there is no vision, the people perish,” (Proverbs 29:18). 
Surely the same is true for an organization. Visions have two very real effects: (1) they provide the 
overall tone or goals of an organization, what it is and what it is becoming, and (2) visions are created in 
each individual at whatever level he or she is, providing inspiration, motivation, energy, challenge, 
direction, etc. , producing development and growth. Belongingness becomes a major attitude. Maybe in a 
real sense, a culture is created. Many words can be used to describe the effect of vision: inspiring, 
empowering, directing, motivating, etc. To create the organizational, and thus, the individial vision, 
requires management to build and invent images, symbols, etc. These, in turn, develop the meaning, the 
culture, required to foster in every worker his own visions. It is only effective to the degree that it is 
caught and lived by every organizational element and individual. Fundamental in all this are some 
subprinciples. One that has common usage is “a catalyst to change is education,” remembering that it is 
only through change in individuals that the goal is achieved. Somewhere in the distant past, I read or 
heard a statement of another important principle related to change that went something like this, “to gain, 
you must lose.” Something must be given up for growth which requires loss. Losing hurts and the hurts 
must be dealt with. Also, to give up something and reach for an unknown is risk taking. Leading people 
to vision, whatever the technique, requires that the management understand the educational and loss 
principles. The manager is dealing with the lives of individuals including his own and this cannot be dealt 
with lightly. Good management is never easy; in fact it too is costly. It is not the intention here to deal 
with the hows of implementation, the management books referenced cover this from all aspects. 

3. Perspective 

The perspective from which one views the problem is different at each level. At the top, one does 
not see or at least manage or plan the details of a parts analysis or test. At this level, the view must be 
broad (of the whole) while understanding the need for the indepth, concentrating on the overall results 
while leaving the details to the lower level. Conversely, the detailed analyst must plan and execute the 
details of the part without managing or planning the details of the overall. He does, however, have a big 
impact upon the overall through communication, dedication, etc. 

4. Approaches 

Management styles are very diverse: individualistic or group, autocratic or democratic, etc. There 
are many choices, however, no one approach is absolute. All must be adapted to the personality of the 
individual. In other words, do not get carried away mimicking someone else. Be yourself while applying 
some basic principles and common sense. While coaching earlier in my professional life, the principal of 
the school where I taught gave me a valuable lesson. He had been a very successful coach and envisioned 
coming into the gym each day helping a new young coach get his feet on the floor. After one week we 
had a discussion in which he said, “Coach, I can’t help you with the practice, it won’t work. You have to 
do it your way. I can only help by giving you observations away from the players. I have to transpose 
myself into your thought process to help.” What insight into the very basics of management. 
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5. System Emphasis 


The hardest management problem I have observed in the aerospace world is: How do you insure 
that the systems approach (systems engineering) is understood and accomplished? The tendency is to 
become narrow, only focusing on either a part, a special discipline, or test, etc. While this has to be done 
for penetration, etc., it must occur in the system context. Several attempts have been made to solve this 
problem. All have merit, however, the one general characteristic that appears is: Regardless of the 
forum, there must be an air of openness and technical integrity. This must be emphasized to such an 
extent that no one is afraid to raise a concern, issue, or opinion. Diverse disciplines discussing and 
commenting on each others area is fundamental to a system focus. 

A fairly successful approach was instituted by Level II integration for the Space Shuttle program. 
Figure 18 is a schematic depicting part of the system. Notice that the final Level II programmatic deci- 
sion is made by the Program Requirements Change Board (PRCB), however, an elaborate system of 
supporting arms is in place to provide information, etc. One arm is the Systems Integration Review 
(SIR). The SIR has two major support groups: the Propulsion System Integration Group (PSIG) and 
the Ascent Flight Systems Integration Group (AFSIG). Only AFSIG is shown on the chart. The funda- 
mental characteristic of PSIG and AFSIG is that they are engineering recommending groups, not 
program decision making bodies. This creates an atmosphere of openess with emphasis on engineering. 
Supporting AFSIG and reporting to it are the various technical panels (loads, control, performance, etc.) 
who meet to work their problems. All levels of exchange exist between the panels and AFSIG. Recom- 
mendations carried from AFSIG to the SIR and PRCB are generally introduced by AFSIG, but the tech- 
nical side is presented by the panels. The same holds true for PSIG. Members of AFSIG/PSIG are the 
various technical discipline leads and program leads from affected NASA centers. Contractors are ad hoc 
representatives. The panels, however, draw their membership from both NASA and its contractors and 
include all relative disciplines. Problems, concerns, etc., are therefore vertical and horizontal, producing 
overall completeness. The freedom to move up and down or to the sides is one key to success. All 
criteria, analysis, tests, etc. , flow through the groups. Because of this flexibility, a panel or panels can be 
asked to penetrate a concern by any group above through AFSIG or can, on their own, penetrate a 
problem. 

Other approaches have worked equally well for short periods of time (less than 1 year) to work a 
particular problem. This is accomplished by creating an information center, interdiscipline, government/ 
contractor co-located ad hoc group to solve the problem. At least three activities in the Shuttle world 
involving major problems were worked in this manner: (1) Shuttle main engine (verification of SSME for 
the first Shuttle flight, (2) orbiter tile (reentry heat protection system), and (3) SRM redesign (redesign- 
ing SRM to eliminate the cause of the 51-L accident). The idea of ad hoc teams is at least two-fold: (1) 
isolate them from other problems, concerns, etc., and (2) have all disciplines and project together to 
insure crosstalking, communications, and reduce problem solution time. The skunk works approach is 
essentially the same. 

Another technique which can be used to accomplish the same system goals is the design review. 
However, many come too late except for removal of critical problems. These program reviews are 
sequential starting with (1) Preliminary Requirements Review (PRR), (2) Preliminary Design Review 
(PDR), (3) Design Requirements Review (DRR), (4) Critical Design Review (CDR), (5) Design Certifi- 
cation Review (DCR), and (6) Flight Readiness Review (FRR). Various programs will use different 
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Figure 18. Structural loads/dynamics block diagram. 





names for this same approach. Special reviews and audits can also be interspersed to further augment the 
confidence. A simpler way of looking at this is shown on Figure 19 which treats the areas as configura- 
tion traceability improvements, technical interchange meetings, and validation. A partial listing of what 
is in each is included. 

6. Training and Selection 

A major problem throughout management is the training and selection of future managers. This 
process is of major importance to the future of any organization, but is just as important to the adequacy 
of design and verification. In general, two overriding skills are required for management: (1) social skills 
and (2) technical skills. Selections tend to be made on the technical skills level, yet most of a managers 
time is spent handling people. Regardless, once a manager is selected he must perform three tasks well if 
he is to succeed: (1) conceive, (2) sell, and (3) follow through. The ability to see interrelationships and 
their visualization is the secret to communication. Communication is not listed in the three tasks since it 
is a skill cutting across everything. Obviously, many other things are important, such as integrity, and 
should be included in the criteria for selection. Organizations are clearly guilty of not emphasizing the 
manager selection/training enough. 

7. Communication 

Information flow, communications development, and update of symbols (data patterns, etc.) are 
other prime tasks of management. Modern day computers with all the special software for data basing, 
graphics, etc., have put an excellent tool in the managers hands to accomplish this task. The symbols 
(patterns) and the supporting data bases must be accomplished for all areas such as personnel, resources, 
testing, engineering, documentation, etc. For example, when the time comes to certify a design for 
operations, two major tasks exist for management: (1) insure that the hardware indeed technically has 
met all requirements, and (2) show traceability of how the requirements flow down and have been met. 
The first implies revisiting indepth all engineering while the second is essentially a paper trail. Figures 20 
through 24 were developed by Rocketdyne to illustrate at a top level how these two tasks were accom- 
plished for the SSME for the first Shuttle reflight following the Challenger incident. Figure 20, going 
clockwise, traces the requirements through the hardware to the as-built/design capability. Figure 21 starts 
with the system description moving through all pertinent requirements and controls. Figure 22 is the 
documentation trail from requirements verification, while Figure 23 gives the total part history. Figure 24 
lists the verification requirements documents by assemblies. This document includes the requirements 
and verification plan, including verification complete sign-offs. Many other approaches have been used 
and work. This example was not chosen because it is necessarily best, but as a means of illustrating part 
of the manufacturing and control required to assure adequate design and verification. 


8. Summary 

Before leaving this snapshot of the managment role in assuring adequacy of structural design and 
verification, it is necessary to return to key areas mentioned. 

a. Emphasize People 

The first and foremost is that people are the fundamental resource that makes or breaks design. If 
that is true, what can managers do? Nothing much new is on the scene, however, basic principles alluded 
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Figure 19. Structural validation process. 







Figure 20. Typical subsystem organization. 
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Figure 21. System volume organization. 
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• ESSENTIALLY 25 LEVEL IV CEI’s CATEGORIZED BY MAJOR COMPONENT AND/OR 
SUBSYSTEM 

• PROVIDES ALL DESIGN AND VERIFICATION REQUIREMENTS AT COMPONENT 
LEVEL 

• PROVIDES TRACEABILITY TO THE CEI/ICD 
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Figure 24. Design verification specifications (DVS). 



to by Drucker [45,46,47], Peters [44,48,49]. etc., need repeating. First, whatever the individual has of 
value to the organization is within himself. As Drucker says, “His development is not something done to 
him, it is not another or better way of using existing properties. It is growth, and growth is always from 
within. The work therefore must encourage the growth of the individual and must direct it” [45]. This 
means that all work must challenge the worker, motivate him to want to contribute and grow. Whether 
one does this by objectives, managing by walking around or all the other techniques required to get the 
worker in the right job and be a part of the organization is up to the individual manager. Recognizing the 
principle of the human resource is not optional if an organization is to insure adequate design. This means 
that somehow the responsibility has to be put at the bottom of the pyramid used initially and not at the top 
as is generally thought. Inverting the pyramid as Peters suggests is very close to the concept being 
pursued. This means that individual responsibility is the key to performance. It also means that he is a 
part of the organization, that information flows up and down, that he feels a part of success or failure of 
the product, and that management is a support to him for accomplishing his tasks. In other words, he 
should participate in the planning. This is even more true of the professional workers with which the 
report is dealing. 

Technical management or professional management is not addressed extensively in literature, yet 
that is what aerospace and, in particular, structural adequacy of aerospace systems is all about. How the 
bottoms up and tops down is implemented is not absolute. The basic principles are clear and involve (1) 
value of individual, (2) traceability from requirements to validation, (3) technical knowledge and under- 
standing, (4) communication, (5) vision/culture acceptance and values. 

b. Prioritize Tasks 

One task inherent in the others discussed, but mandatory in the aerospace field is the planning/ 
meshing of tasks and resources to the right areas. Drucker made the observation that 10 percent of the 
effort accomplished 90 percent of the results, while 90 percent of the effort is expended to obtain 10 
percent of the results [46]. Cost, etc., follows the same general trend. Obviously, for all organizations, 
this statement is partly true, only the percentages are debatable. This means that one of the principles of 
management and, therefore, a prime task is to understand the tasks, set proper priorities, and allocate 
resources to emphasize results. As stated previously, it is very easy for management to fall into the trap 
of letting the project/crisis do the prioritization and resources allocation, aggravating the problem (Fig. 
25). Management must make judgements on which tasks have a real payoff (results) and put the 
resources against these tasks. In most cases, for example, in analytical understanding of structural 
characterization, 90 percent of the knowledge can be obtained fairly cheaply while acquiring the addi- 
tional 10 percent of the answer is very expensive. Many times a simple redesign (for example, changing 
fastener bolts to higher strength to eliminate detailed nonlinear analysis) can be implemented quickly, 
reducing analysis and testing costs substantially. This reinforces some of the statements made relative to 
performance versus sensitivity. 

c. System Focus 

Management must create the system focus and must set the performance requirements that put 
technical excellence and integrity above schedule and cost. Otherwise^ project schedules/cost become the 
management tool and criteria leading to insufficient products. Space Exploration depends on highly reli- 
able technology and cannot afford these deteriorations. This does not in any way remove the importance 




Figure 25. Conflict of expectations. 

of schedules/cost but puts them in the right focus. A complicating factor for aerospace is illustrated on 
Figure 26. In such a technology extending field, there must be a balance and interaction between ongoing 
projects, future projects/strategic, and technology mentioned above. If too much emphasis is placed on 
ongoing projects, the schedules and demands of the project control and manage leaving nothing to future 
goals and the development of the technology to insure it. Even the technology required to solve project 
development and verification problems is very short sighted and short lived. In other words, without 
special attention, any technology resulting from project tasks is incidental. With planning based on tech- 
nology shortages uncovered in project work, good short-term practical technology applicable to several 
projects will result. A better approach is to combine with the project-focused technology, a base tech- 
nology plan that is more generic and future oriented. This produces and insures a healthy organization 
with proper skills, resources, etc., to handle future programs. This latter effort (base technology) can be 
accomplished in NASA either as a part of the development center’s manning or at the research centers. It 
probably is a mistake to put it all at either one or the other center. The development centers drive tech- 
nology needs and do the practical application, while research centers do best at developing long term 
research techniques. Both need to be involved and communicating. Fundamentally, project management 
and engineering must be a team that collectively sets proper priorities and goals, allocates resources pro- 
perly, and integrates analysis, testing, hardware, and operations. As one manages this tri-focus, interac- 
tion and proper balance are necessary at most levels. In order to have healthy organizations and insure 
present and future structural integrity, both engineering and project must share equally in making this 
happen. 

This task is complicated by the fact that engineering tends to spend its energy on problem solving 
and potential problem analysis with minimal efforts on visions and conceptualization, although any 
project, hardware, etc., is the result of the vision process. In other words, the foundation of any 
aerospace effort is the conceptualization. The success, however, hinges on the ability of organizations 
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Figure 26. Management dilemma. 

and individuals to solve problems and avoid potential problems. This latter effort is not routine, maybe 
not as glamorous as the visionary stages, but requires a high degree of innovation and insight challenging 
the very best of talents and skills. This effort results in the operating hardware fulfilling the original 
visions and dreams. The task that management faces is how to keep all these efforts in focus. The danger 
in problem analysis is the negative emphasis that kills the enthusiasm for moving forward. The optimistic 
viewpoint is very necessary for success. 

The lessons learned in the management/control area for aerospace are outlined in the summary. 


IV. ANALYSIS AND TEST 


What is the overriding principle in analysis and test? Where must the focus be? What is the 
viewpoint that shapes all that is done that drives the process? Is it not developing and having a firm 
foundation of basic principles, not detailed analytical formulations but pure and simple understandings 
and representations of the concepts and principles? Gordon’s two books, “Structures, Why Things Don’t 
Fall Down” and “The New Science of Materials or Why You Don’t Fall Through the Floor,” are two 
examples of the concepts and viewpoints being discussed. No engineer, regardless of his discipline, 
should be without these books. Books of the same nature exist for other areas. They teach you how to 
visualize and think a concept through. All good engineering starts there. The rest are aids. Coupled with 
this are the simple hand analyses with free body diagrams, flow, etc. Each engineer must accept this 
challenge and the corresponding responsibility for growth and reaching the defined objectives. Once 
these principles are internalized, good structural design results (see section on management). 
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The pyramid concept (Fig. 25) fits analysis and test perfectly. System analysis must be performed 
first at the top to define generic data flowing from there down. After the initial loop, both bottoms up and 
tops down intermingle. This intermingling, however, must always keep the system focus. Figure 27 
shows a flow of the basic system task from an analysis and test standpoint showing the waterfall and the 
iteration loop. Not all interacting disciplines are shown; however, those illustrated are fundamental to 
structural integrity. Structural integrity is inherent within each of the individial disciplines such as 
propulsion as well as the overall systems structure. In other words, the structure must withstand all 
propulsion induced environments while not reducing the basic performance. Through the process of 
system analysis, in conjunction with sensitivity and optimization studies, a balance in design, reliability, 
performance, and margins can be achieved which minimizes cost and assures robustness. Figure 27 does 
not show how this is accomplished, yet this is a mandatory task in structural integrity. All have seen the 
comical charts illustrating how designs would evolve if the focus was on a single discipline such as 
propulsion or control. Clearly, design must optimize between structures (including weight), propulsion, 
flight mechanics, control, loads, and stress. Structures become fundamental in these trades. How you 
shape structure, join structural elements, integrate elements, etc., plays a major role in the resulting 
integrity. The various interacting disciplines must provide some general constraint/sensitivity type algo- 
rithms to this process to balance or optimize the system. For example, if one is designing a control 
system, the mass, etc., of the control effectors becomes a key item. Trades between structural geometry, 
passive damping, etc., versus active control levels produces a design with more integrity. Not shown in 
this loop are the other interloops between criteria, philosophy, and documentation. For example, whether 
one designs for no failures, fail safe, fail safe-fail operations, etc., has a big influence on the design and 
or the analysis and test approaches, schedules, and resources. Vertical and horizontal communications 
are imperative. The statistical method used to treat parameter variations and failures has the same impact. 
These areas will be discussed later. 


A. Analysis 

As mentioned previously, an early part of the analysis process is the combined optimization sensi- 
tivity studies. These studies start at the total system simulation level and progress down to comparable 
studies that are conducted at each level including the piece parts in many cases (Fig. 28). It should be 
pointed out that these do not stop with the design selection but continue as more knowledge is acquired 
and design changes ensue. Completion occurs only when design is validated and in operation and then 
only if no problems occur. 

The importance of developing these data trends focuses the process identifying major areas of 
concern. Coupled with this data must be a developed set of patterns and symbols that include interacting 
flow diagrams, free body diagrams, limiting cases, and hand or simplified analyses. As stated pre- 
viously, limited conditions or bracketing analyses are a fundamental part of this simplified work. It 
should be pointed out again that these occur at all levels, in all program phases, for all disciplines and 
must be communicated in all directions. In the final essences of the process, the engineer working the 
problem is responsible for the planning and communications. It is not enough just to know certain facts. 

1. Illustration of Approach 

For illustration purposes only, structural analysis will now be carried up and down through the 
tiers of activity. Obviously, all areas such as control will require the same process. Various approaches 
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— FATIGUE-FRACTURE MECHANICS 


Figure 28. Analysis tier. 

exist for determining structural loads and the resulting structural margins. Figure 29 is a very simplified 
flow diagram of the approach. These margins are stated as stability, safety factors on ultimate and yield 
stresses, fracture limits, fatigue lifetime, reuse criteria, stability limits, and operational criteria. Regard- 
less of the techniques chosen, consistent and compatible approaches must be used starting with the 
system analysis, system loads analysis, and continuing through elements to the smallest part analysis. 

The approach chosen for structural design and verification must be comprehensive, consistent, 
and focused. Therefore, it is necessary that common models, environment data bases, analysis 
approaches, and criteria be employed by all vehicle or system elements to insure a compatible system 
risks assessment. The assurance that this happens involves proper organization and control 
(management). 

Up front, the basic problem facing structural analysis and verification should be clearly stated. 
The problem: All analyses are simulations which are not complete (limited), which attempt to predict 
trends of what will happen. The same is true of test. As discussed in the general section, all these partial 
attempts to model or test reality are melded together. How these many pieces are put together determines 
the validity of the design. 
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The basic concept and philosophy of this approach are shown in Figure 30. The process starts 
with each element and its subelements providing the structural models and all pertinent parametric data 
(example: SRB thrust, thrust rise rate, pressure) to the integration organization for the system loads 
analysis. These models must be compatible with all other element models and with the final element 
stress analysis models. The system integration approach, parameter variations, statistical criteria, and 
verification required are determined in various ways. Using these criteria, loads analysis for each design 
condition (parameter combinations with natural environments) are to be conducted and loads developed. 
Figure 30 shows some of the natural and induced environments used to determine the loads. These 
analyses are made in a statistical manner such that the resulting responses (loads, etc.) are at a 99.7 per- 
cent probability or some other predetermined level of occurrence when varying all system parameters and 
environmental values within the expected range. Included are all vehicle parameters and natural environ- 
ments, such as wind speed, wind shears, and wind gusts. 

2. Integrated Analysis 

The approach used to generate loads will now be elaborated on for the Space Shuttle liftoff regime 
in order that the external loads analysis process is better understood. The first step (Fig. 30) utilizes test- 
verified dynamic models of each element (SRB, ET, SSME, orbiter, payload, MLP). These models are 
coupled together using proper interface models in conjunction with either substructuring or modal 
coupling techniques. This step produces an overall vehicle dynamic model. Step 2 takes this complicated 
dynamic model and descriptions of all known forces and formulates a set of describing differential 
equations which, when integrated time-wise, will describe the characteristics of the structure. Integration 
of the resulting equations, using either digital or hybrid computers, produces the responses and external 
loads (step 3). Since the generalized forces are not precisely known (i.e., only known to a test-verified 
statistical level) a discrete load case will not describe the design load. In phase IV, these characteristics 
are used as forcing functions to obtain more detailed knowledge of each element. Phase V uses the output 
from phase IV to accomplish even greater detail information of parts, critical areas, etc. This output 
establishes all margins, etc., used for design or verification. 

This chart does not deal with the procedures, codes, etc., required to accomplish these steps. 
These choices depend on many factors, such as complexity, skills, computational equipment, etc. How- 
ever, with modern day computers, integrated output should be maximized as shown on Figure 31. 

Notice that automated outputs such as loads and stress matrices feed directly to the stress analysis 
as does loads spectra to the fatigue. This reduces chances for errors and increases efficiency. All the 
interacting flows and iterative loops are shown. Loads and stress analysis, although considered by many 
to be separate disciplines, must be really worked together or at least very closely with constant commu- 
nication. Obviously, thermal and control fall into the same category. The chart clearly shows the inter- 
action between different steps and between loads and stress. The Shuttle SRB aft skirt failure illustrates 
the requirement for communications and interaction. Early Shuttle loads analyses conducted using 
simplified models of the launch pad and the SRB skirt produced a set of loads that, overall, was thought 
to be accurate for the prelaunch SSME thrust buildup phase of launch. It was understood that major skirt 
load would arise from vehicle weight combined with the SSME thrust force. At full thrust, the four hold- 
down posts,.away -from the .orbiter (Fig. 8) are loaded in compression not only from weight but also from 
the vehicle bending due to the SSME thrust. What was not understood was the sensitivity ol the local 
weld stress near the holddown post to the pad stiffness. Stated differently, the radial load component 
(Fig. 32) shows how the compressive load creates the large tension stress in the weld. The skirt angle 
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Figure 32. Aft skirt post with axial, radial, and tangential load. 








splits this compressive load into two components, one axial and the other radial, lhe radial component, 
depending on the pad stiffness, moves the posts outward, bending the skirt skin locally creating high 
tension stress. Figure 33 shows the sensitivity of the local weld stress to radial load changes. Two skirts 
have failed in structural test due to this effect. To date no credible failure mode has been identified. 
Coupon testing shows that large strains (2.5% or greater) are required in the weld area and, in the heat 
affected zone, the highest stress measured in the structural test at failure was 0.8% strain. Additionally, 
the loads generated for the design case were based on varying parameters to maximize the average load in 
the skirt post, not the local load where the failure occurred. As a result, special materials testing has been 
required, a detailed test verified MLP and local skirt models were developed, and additional loads cases 
developed. Several messages are apparent: (1) understand the sensitivity; (2) develop models, analyses, 
etc., to cover that sensitivity; and (3) provide for healthy interdiscipline communication. The 
requirement for communication and understanding between disciplines is clearly illustrated. 

This is a good place to deviate slightly and discuss the requirements of high performance systems 
for an adequate but nonconservative statistical statement of loads and structural margins. The general 
approach has been to calculate loads and determine a 3a equivalent static peak load. This equivalent static 
3a peak load is applied to the stress model to get static stress. Safety factors are then applied to the static 
stress. If one wants to take out some of the conservatism inherent in this approach, one must apply statis- 
tical techniques. The best way to achieve this is by using the approach shown on Figure 29 where an 
integrated analysis is performed where the output is stress, etc. Several codes are being and have been 
developed that will accomplish this with stress as the output. Many statistical or probabilistic approaches 
are available that produce time consistent stresses in any form desired. This includes the spectra for 
fatigue. Obviously, if other states (strain, deflection) are desired, these can be calculated in the same 
manner. The message is clear. If analysis is to stay up with the performance requirements, then an 
integrated approach is required. This approach leads to a more definitive probabilistic statement, usually 
less conservative than the classical methods of the past. The problem that many feel in a piobabilistic 
approach is the loss of the commonly used safety factors and margins ol safety replaced by the prob- 
abilistic statement. Retraining/education is required to bridge this gap. 

3. Subsystem Analysis 

The next level of analysis and test develops the same kind of detailed flow for the resulting dis- 
ciplines and margins such as fracture mechanics, fatigue, vibroacoustics, structural, static, and dynamic 
testing. Figure 34 shows this next level for one fracture mechanics plan for part of the SRM. Notice that 
it starts with the stresses from the stress analysis and proceeds to use special fracture mechanics analysis, 
materials data base development, analog testing, NDE, proof testing, etc., to arrive at a verified system 
for flight. Along with this flow and testing, there is a need for parametric data which shows crack initia- 
tion, crack growth, crack instability, etc., so that one can deal with damage to learn design appioaches. 
Figure 35 shows the same detailed flow for fatigue life assurance including test and verification. This is 
essentially the same flow depicted in Reference 52. 

References 7 through 43 are more detailed reports dealing with the specifics of the approach laid 
out. Implementation of these approaches requires the development of detailed procedures, methods, 
codes, etc. , to carry out the task. It is very important that these be developed and updated to assure good 
analysis. 
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Figure 35. Fatigue life assurance-information flow diagram. 
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Procedures, codes, etc., are not the total story. Two key ingredients make the system work: (1) 
the accuracy of the input data such as materials properties and environments, and (2) the modeling 
assumptions and model development. The output is no better than the input. The validation process is the 
final analysis task. Figure 36 illustrates the flow and the various parts starting with requirements and 
proceeding to the as-built hardware. The model validation is a continuous process from early in a 
program to the end. It involves the sensitivity analysis but more importantly the testing to be discussed. 
In general, analysis is only as good as the validation testing whether it is to set parametric data or final 
model verification. 

4. Aids 


Many aids, in terms of handbooks, data bases, and general principles, are needed to guide analy- 
sis, aid understanding, and interpret data. References 17 through 43 have many examples of this type of 
information. Figure 37 shows the relationships of applied load history, strength, and damage size with 
time. Obviously, this curve exists for each material and is therefore unique for each. For a detailed dis- 
cussion of the curve see Reference 52. The same is true for Figure 38, which represents typical residual 
static strength data. 



Figure 36. Structural validation process technical. 
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Figure 37. Relationships of applied load history, strength, and damage size with time. 



Figure 38. Typical residual static strength data. 




5. Technology 


Analysis must also deal continuously with the technological issues inherent in the tasks. These 
must be kept at the forefront, constantly challenging the approach being used. For example, some basic 
technology questions that have been raised in the structural disciplines are: 

(a) Validity of Goodman’s. Necessary constraints. 

(b) Failure criteria for ductile material. 

(c) Methods for handling fasteners, bolts, threads. 

(d) 3D stress field effect on fatigue, fracture mechanics, etc. 

(e) Combination of low and high cycle fatigue. 

(f) Accumulated linear damage factor rules. 

(g) Nonlinear fracture mechanics. 

(h) Residual stress. 

(i) High cycle fatigue fracture mechanics. 

(j) Single cycle versus multiple cycle proof testing. 

Similar lists are available for all major disciplines including, but not limited to, systems, thermal, 
control, fluid flow, propulsion, flight mechanics, etc. 

Key lessons learned are included in the summary. 


B. Testing 

Testing uses most of these same principles discussed under the analysis section, however, some 
additional principles are involved. 

1. General 

Primarily the principles of testing, whether to acquire understanding or for final verification, are 
fundamentally the same as those just listed. Good testing always starts with analysis (pretest analysis) of 
the test article and test setup (facilities). This analysis, in conjunction with all the analysis previously 
discussed, is used to define test conditions, plans, instrumentation and range, constraints, etc. It is very 
important that all test boundary conditions (facilities, test support equipment) be totally understood and 
defined. A classical example of understanding boundary conditions occurred on the Saturn I vehicle as a 
result of the dynamic test conducted to verify modal analysis used for control system design and loads 
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determination. Due to the configuration complexity (cluster tanks) and modal analysis technology (or 
lack thereof) analysis to test correlation was not as good as desired. Matching frequencies led to a mis- 
match of modes and vice versa. It was hypothesized that the test suspension system was coupling with the 
structure altering the modes. One engineer thought that he could remove this effect by special data 
reduction/evaluation techniques. Due to data accuracy problems, this process created several psuedo 
modes with high gains which coupled with the control system creating an instability. The launch of the 
first Saturn I vehicle was delayed a few weeks while the problem was resolved. Much publicity occurred, 
even a big article in Fortune Magazine. The problem was resolved by showing that the experimental 
modes were accurate and the control was stable. Many successful launches without control system 
change verified the decision. Dynamic tests since this time have given proper emphasis to boundary con- 
ditions/suspension systems. Many good tests are invalidated because of inappropriate boundary con- 
ditions [21] or the lack of understanding thereof. The pretest analysis is very useful in controlling the test, 
making decisions, and understanding data. 

2. Test Conduction/Data 

This leads to the next step which is test conduction and data acquisition. As much diagnostic data 
and automation should be emphasized as possible to enhance test conduction. Analyzing and evaluat- 
ing the data are very important to test success. Establishing various ways of cross plotting, parameteriz- 
ing, etc., should be the norm. Many times digitizing the data at high sample rates gives much flexibility 
to this process. Part of this process of evaluation is correlating the results to the pretest predictions. Many 
times this can be done in real or near real time by storing the predictions in the computer used to analyze 
the data. The final step is to update the model/simulation based on the test data. This cannot be 
emphasized enough since this model will be used for variations in projected operations, MR (manufactur- 
ing requirements or materials requirements deviation) resolution, and operational constraints, etc. All the 
previous points in terms of documentation, data basing, communication, etc., apply to testing. The 
individual again is the key resource and makes or breaks the test. Much more could be said about testing. 
There are many types of test: (1) dynamic, (2) static, (3) fatigue, (4) fracture mechanics, (5) proof, (6) 
burst, (7) vibroacoustic (development, qualification, and acceptance), (8) thermal, (9) flow, (10) propul- 
sion system hot firing, (11) development flights, etc., all of which have their specialties and nuances. 
These are not a part of this paper. Many references exist [17 through 42]. Regardless of the area, how- 
ever, one overriding viewpoint is important. One must start with the smallest entity possible and under- 
stand it fully, then add the next level and understand it. This buildup continues until the total system is 
tested together. This last step may not be accomplished on the ground, but becomes a part of the initial 
operational or developmental phase with proper safe guards. This sounds like an advocacy of bottoms up 
only. This is not true. Various levels of tests from the tops down should be intermingled in parallel in 
order to better understand the parts and the system. Not all testing should be full scale. Scale model test- 
ing conducted properly is very valuable and can be a fundamental or predominant part of the test 
program. Even flow testing, properly scaled and analyzed, has been very successful as demonstrated in 
the field of aeroelasticity. It is mandatory, however, to understand the scaling assumptions and therefore 
the limitation to properly interpret the data. 

3. Developmental 

Development testing to understand the basic phenomenon, define parameters and sensitivity, and 
to validate analysis is mandatory for successful design and validation although it is a principle bypassed 
many times to save money. This type of testing covers both the environments and the structure as well as 


56 



materials characterization. For example, flow testing of a turbine with various diversion angles, contours, 
etc., can help select the better design and also provide validation of the analytical prediction. Structural 
testing can show potential problem areas as well as analysis validation. Destructive testing to understand 
failure modes and limits is a good approach, if possible. 

4. Static 

Static structural testing, and, in particular, testing of large hardware, is difficult to accomplish. It 
is mandatory to apply and balance loads properly. This involves not only the load lines (application 
method), but the hardware alignment, instrumentation, and backup structure characterization, all of 
which are fundamental to getting good data. Two principles are very important here: (1) to look at all the 
details but always with the overall system in view, and (2) to understand the test as much as possible from 
the analysis viewpoint and determine what can be expected. Testing for testing’s sake buys very little. A 
third principle that generally comes into play is to have all potential diagnostic tools in place so that as 
surprises occur they can be understood and the test can proceed. 

5. Summary 

Fundamentally, one must fully understand what problem one is trying to solve, intepret, etc., in 
order to properly test for it. Running a test with careless analysis data leads to the wrong answer and 
future failure. Proper testing requires the team effort between all interacting disciplines with complete, 
open lines of communication. This goes from knowing what hardware configuration is being tested to 
understanding the test setup and everything in between. 

The basic principle in analysis and test, as mentioned in the general section, is to accomplish both 
the simplified and detailed analysis. The goal is to design a test program to verify the analysis and corre- 
late and adjust the analysis based on the validation. Understanding this approach principle excludes 
unforeseen, real world deviations. The proof of the pudding comes from flight testing. One must always 
plan for special instrumentation and flight conditions initially to finalize characterization and update 
models. This is a must that has its wisdom demonstrated on many space programs [21]. 

The principles of testing are outlined in the summary. 

Some examples of open or critical structural technologies in testing are: 

(a) Dynamic impedance testing. 

(b) Fracture mechanics plastic testing. 

(c) Combined low/high cycle fatigue. 

(d) Loads combination. 

(e) High frequency loads prediction. 
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C. Analysis/Test Summary 


In dealing with analysis and test, several principles and lessons learned have been discussed. Out 
of all of these has come the overriding principle dealing with integration or systems analysis. If one 
attempts to write down all the potential interacting disciplines, the list gets quite lengthy. In addition, for 
a given space structure, space vehicle, etc., only a few will apply; however, from the list four nearly 
always appear. For example, some of the potential interactions are: 

• Thermal-structural 

• Structural -control 

• Aeroelasticity 

• Trajectory-control-structural 

• Corrosive-structural 

• Propulsion-structural 

• Propulsion-control. 

The four that stand as pillars requiring special attention are (1) loads, (2) stress, (3) material, and 
(4) testing (Fig. 39). One might argue that environments should be included, however, the natural and 
induced environment world is very broad and is included in loads and stress. Also, the same principles 
apply. Looking at these four, why do they separate out as pillars and what overriding integrating 
principle is involved? They separate out because the end product of structural integrity is a statement 
about the structure’s strength, stability, and durability (strength, fatigue, and fracture). Everything 
hinges on this statement - operations, maintainability, life management, etc., including the proof of an 
adequate design. A special relationship between these four pillars is required if structural integrity is to be 
assured. Support from all other disciplines is obvious but these are the foundation. What there is that is so 
fundamentally important with these four is that they cannot be treated as individual black boxes with data 
requirements flowing from one to the other, but must be treated as an integrated whole. They must be 
worked together with each understanding the technical discipline of the other. Obviously, the same 
statement would apply if a structural control interaction problem existed and would require essentially a 
new or combined discipline to work. The principle is clear then: for structural integrity, a stress engineer 
must know loads, materials, and testing; a loads engineer must know stress, materials, and testing; a 
materials engineer must know loads, stress, and testing; while the test engineer must know loads, stress, 
and materials. This knowledge must be at a fundamental and working level, not just some generalities. 
Application of these interacting disciplines must be a probabilistic or statistical way requiring a working 
knowledge of statistical approaches. 

The second principle involved here is that they must work together as a team with constant 
communication in order to assure good results. Testing not accomplished in terms of the real dynamics 
issue gives false security. Materials data bases not compatible with the physical problem or the simula- 
tion under development lead to wrong designs, false security, costly redesigns, or failure. The same can 
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Figure 39. The four pillars of structural integrity. 


be said for the other areas. What is the solution to the problem? As always, no one answer exists, how 
ever, two clear strategies stand out: (1) cross train each engineer for a minimum ol 6 months in the other 
disciplines, and (2) work the problems as ad hoc or informal teams. The argument against each is 
resources, however, the evidence points toward it being more costly not to approach them in some 
manner like this. As a minimum, basic understanding in all disciplines and open communications lines 
are required. This means that management and organizations must recognize this requirement and plan 
for meeting it. 


V. DOCUMENTATION AND DATA BASING 


Documentation and data basing are fundamental and of prime importance to adequate design. The 
importance can be shown in at least two ways: (1) recoids or reference of requirements, specifications, 
assumptions, analysis, test, hardware, manufacturing, etc.; and (2) increased awareness and organization 
focus through the documentation effort. There are many ways to categorize documentation for 
management and control and design validation. Several levels exist, some under very strict formal con- 
trol by program requirements boards, others with only engineering line organizational sign off or 
approval. Top level requirements documents requiring very strict legalistic control are the normal 
requirements documents, CEI specifications and design drawings, COQs, OMRSDs, etc. At a control 
level that is rigid, but not at the same level, are the class of documents which include Design Verification 
System (plans) (DVSs) specifications, procedures, criteria, etc. A different group of documentation is 
the presentation and results of all major design reviews (PDR, CDR, DCR, FRR, etc.) including a very 
formal tracking system for all action items and Review Item Discrepancies (RIDs). Some of this 
documentation is formal handouts of presentations. Very important to the whole process is the next level 
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of documentation which contains all analysis assumptions and results, test plans and results, presenta- 
tions, and data bases. Data bases go from natural environments, materials properties, environmental 
data, analysis, to test results. As discussed previously, these documents must take various forms from the 
very detailed equations and results to some top level summary statement and all the levels in between. 
The choice of how to break out and control these various levels is very important to communication and 
traceability. It is also very important that key results be published in open literature so that lessons 
learned, etc., get disseminated throughout the aerospace community. 


A. Symbols 

The discussion, thus far, tends to be centering on what is done or controlled at each level, 
although in some cases this is the same as a bottoms up or tops down type thinking. What is clearly 
missing is what symbols, for example, at the lowest level, to 'sendup to the higher levels of documentation 
or management or conversely, to send down. For example, it is obvious that the detailed equation or 
results of a stress analysis are not required; however, the fact that the work was accomplished and some 
summary or encompassing symbol should be presented or developed. In this case, maybe it is the 
minimum margin of safety in a structure on yield and ultimate. Even the general stress level throughout 
the structure may not be required, but colored contour plots of stress level patterns in conjunction with 
the minimums may convey more than enough (Figs. 40 and 41). Lateraly, however, or in the case of 
audits, detailed communications of every facet of the analysis are required. Also, if design changes or 
performance enhancement, etc., occur, the detailed documentation is a must to eliminate complete 
reanalysis and test. Matrix-type summaries that list all analysis, test, etc., performed, the responsible 
individual, the documentation number, date, and applicable part or structure are very important for trace- 
ability, management, and visibility (Fig. 22). Typically, the documentation for structural durability for a 
given part would or should flow down as shown on Figure 40, as an example. Obviously, the tree would 
vary substantially in terms of number of analyses, test, etc., required to complete the picture; however, 
the basic flow down stays the same. Hirsch summarized the need for symbols in Reference 56: “Only by 
accumulating shared symbols and the shared information that symbols represent, can we learn to commu- 
nicate effectively with one another in our national community.” With this brief documentation overview, 
the following discussion will deal with basic principles and lessons learned from the reviews. 

1. Interdiscipline Communication 

Although a wealth of data exists in the materials world, material data bases, or the lack thereof, 
and communications between disciplines concerning these materials properties has been a recurring 
problem. Evaluating these discrepancies has shown that it is not necessarily a poor documentation 
problem but a multi-faceted problem cutting across many areas. In fact, it probably should be classed as 
an integration problem. It cannot be stressed enough that adequate communication and understanding exist 
across the disciplines. In dealing with the high performance minimum margins system, a very specific 
category of data is required to solve or analyze each problem area. This means that all disciplines supply- 
ing input data to structural analysis, for example, must understand in detail in terms of the problem being 
analyzed and the various data requirements. Otherwise erroneous answers result. Another part of this 
problem is the currency of the data base in use. Many instances exist where the proper data was available 
but not in the operational data bases. This is a general problem, not just for materials. Materials is being 
selected for an example because of its criticality in structural margins assessments. This again points 
back to the system focus mentioned earlier. 
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2. Problems 


Other problems continue to exist in all documentation. Analysis or test reports, parts histories, 
and other documentation often cannot be found and if they are, then assumptions, summaries, etc., are 
not described. Currency is a major problem. Wrong environments or inadequate models are prevalent. 
For example, the SSME structural audit, although showing the engine to be adequately analyzed and 
verified, found parts that had limited life without Discrepancy Approval Requests (DARs). The cause 
varied between the above to plain oversight. Computer data bases can help in eliminating these problems. 
However, as discussed elsewhere, the final responsibility rests with the engineer, technician, etc., doing 
the job. He must not just do the work but communicate it. 

Examples of documentation have not been shown due to the volume required, however, most are 
familiar with it. The major problem appears to be one of schedule and priorities. In a technology pushing 
the boundaries, crises continue to occur. This moves one from completing documentation to working the 
next problem. A major weakness in documentation is in the high level reports and open literature where 
so little of the key problems solved have been published in any form. This must be eliminated for at least 
two reasons: (1) the technology community needs the information we have developed, in fact, we owe it 
to them since our work is funded by tax dollars; and (2) the professional is due the recognition for his 
work by those other than his own management. 

B. Data Bases 

Modern computer capabilities with networking extending beyond the local organization to 
interacting organizations across the country open up fascinating and mandatory opportunities for 
automated data basing. Software programs and computers are very user friendly allowing managers, etc., 
to interrogate the system. Controls have to be established in terms of who and how updating is accom- 
plished, who can interrogate, and the formal and legal use of extracted data. In addition, many options 
must be built into the programs to interrogate properly and format outputs to fit the users’ needs. These 
requirements must be established based on needs of all potential users. Flexibility must be built into the 
data bases so that they can be expanded, altered, etc. Many examples exist within NASA and its con- 
tractors. One very effective one is the SSME dynamic data base [54]. 

1. SSME Dynamic Data Base 

The planned missions for the Space Shuttle dictated a unique and technology-extending rocket 
engine. The high Isp (impulse performance) requirements in conjunction with a 55-mission lifetime, plus 
volume and weight constraints, produced unique and demanding structural design, manufacturing, and 
verification requirements. In order to achieve the high-performance (Isp), a two-stage pump system is 
used in conjunction with preburners which bum the fuel rich gas, furnishing the power for the pumps. 
This extremely hot fuel-rich gas feeds the main combustion chamber, efficiently developing the engine 
thrust. This system results in unprecedented operating regimes of temperatures,, pressures, and rotating 
machinery speeds. The high rotary speeds and the combustion processes create mechanical, acoustical, 
and fluctuating pressure environments. The volumetric and weight constraints drive the design toward a 
high concentration of energy and minimum structure sizing (thickness, etc.). The energy concentration 
can be illustrated by observing the size of the high pressure fuel pump, which generates 70,000 h.p. 
within an envelope 18 in. in diameter by 30 in. long and rotates at speeds up to approximately 40,000 
ipm. 
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Rotary dynamics is one of the more fascinating fields in dynamics. It is an area all are familiar 
with from one standpoint or another. Any automobile driver has experienced wheel imbalance, brake 
squeal, etc. For the SSME, these problem areas are compounded several orders of magnitude in the high 
pressure fuel and lox pumps due to the high energy concentration (energy density) and speed ranges. As a 
result, supposedly small changes (causes) are greatly magnified in the responses. Since bearing life of 
these pumps is limited and is to a large degree a function of the dynamic response, the health of the 
pumps is monitored using acceleration data. These data are obtained from a set of accelerometers 
mounted on various locations of the pump housing. 

The importance of this information to the SSME and the inability to analytically determine many 
effects in this machinery have led to the development of a very comprehensive set of data reduction, data 
evaluation tools, and an automated data bank of these data for all hot firings. Over 1 ,000 engine firing 
results are available in this data bank. Problems have been characterized and normal pump characteristics 
have been statistically formatted. Through the use of this data base system and accelerometer data from 
each engine firing and Shuttle flights, pump status is determined and refurbishment scheduled averting 
major problems. 

First, the response statistics for three accelerometer measurements on the lox pump for all 109 
percent power level firing (percent of original engine design thrust level) are shown on Figure 43. Two 
tables are given, one for the composite level (0 to 1 ,000 Hz RMS levels) and the other for synchronous 
(levels taken from spectrum at rotating speed). Information comparable to this for all pumps and their 
measurements and power levels is available. Also, data can be compiled by pump, engine, build, etc. , as 
desired. 


A typical pump response (isoplot) is shown on Figure 44. The predominant response is synchro- 
nous with a small 2N response. Isoplots are a series of spectrum plots every 0.4 sec, giving a pictorial of 
frequencies versus time. Amplitude is shown but is hard to read due to the overlapping of spectrums. 
Individual spectrums are used to get correct amplitudes. Anomalous behavior would show up as addi- 
tional frequencies on the isoplot. 

Figure 45 is an isoplot for a pump with rubbing. Notice the distinct 3N (3 times synchronous fre- 
quency) and 4N frequencies. Also, notice that distinct frequencies exist slightly above 3N and 4N. These 
are indicated on the individual spectrum placed above the isoplot. Many times, these frequencies are not 
constant with power level but move around, indicating something like brake squeal going on (Fig. 46). 

2. Vibroacoustic Criteria 

Fundamental to structural integrity of space vehicle components such as gyros, actuators, valves, 
electronic boxes, etc., is the development of vibration criteria for calculation of loads and for develop- 
ment, qualification, and acceptance testing. These criteria are developed in a pseudo empirical/analytical 
manner using data bases consisting of the input acoustical spectrum and a known system including attach 
structure and the recorded response spectrum of the input. Categorizing this data by component mass and 
attach structure, new criteria for different components mounted on the same type structure can be 
developed through scaling the input acoustic spectrum, component mass, and mounting structure thick- 
ness. Automating this data base has reduced criteria development efforts by a factor of 3 or 4. Figure 47 
shows typical data bank data, while Figure 48 shows the use of that data bank to generate new criteria. 
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As stated previously, data bases exist in most engineering, operations, and hardware manufactur- 
ing areas and are key to structural integrity and to project management. Much work on data bases and the 
appropriate reference symbols needs to be accomplished. These data bases should be accessible by both 
government and industry organizations that have concerns and should be accomplished with cross 
country data linking, as is presently done with the SSME data. Modern scanning devices can greatly 
enhance the completeness of these approaches. The design and operation of the Shuttle vehicle have 
clearly driven this approach. Future systems must greatly expand it in terms of scope and symbols. 
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C. Summary 

In the general section, a flow down of the documentation (Figs. 20 through 24) was shown down 
to the DVS level. Not shown is much of the supporting documentation to the DVS, such as analysis and 
test reports. For these, one important finding or principle is that each analysis, test, etc. , should have two 
types of summary attached to the basic document: ( 1 ) a set of check-off sheets which provide a quick 
look at the scope, etc., of the analysis/test; and (2) a summary paragraph or statement of the results. This 
latter summary can be used as an input to the next level of documentation and organization. It should be 
kept in mind constantly what the objectives of documentation are: (1) communication, (2) organization of 
tasks, (3) records of work, (4) data base for operations and maintenance, and (5) insights for product 
improvement, etc. 
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VII. PROCEDURES AND CRITERIA 


Procedures and criteria have been combined into one section for convenience. Both are means of 
control or setting minimums in terms of approaches or margins. Both have to be controlled very strin- 
gently and require periodic review for correctness and applicability. Both are mandatory since they con- 
trol the goodness of the hardware, either by how it is analyzed, tested, inspected, manufactured, etc., or 
the margins, etc. , that are built in to cover unknowns. Procedures cover every aspect of the program from 
management, analysis, and testing to manufacturing, maintenance, and operations. Procedures set the 
pace for the total program. Some procedures must be rigidly enforced and constantly reviewed while 
others are merely guidance. For example, the procedures that control hardware assembly are very critical 
while an analysis procedure would be a minimum requirement or guideline. Many times the analyst 
would do more than the procedure calls for. Some flexibility should be allowed in these areas. 


A. Procedures 

Principles that are important to procedures are, in many cases, generic with the one discussed in 
other areas. There are unique areas, however. 

1. Definitive 

First, procedures must be very definitive and clear from two aspects: (1) by whom and how it is 
controlled and maintained, and (2) writeup, instructions, and illustrations, etc. Procedures that are not 
clear or are changed inadvertently can produce bad results. 

2. Requirements 

Second, procedures should be written only where required. One should not try to over control 
using procedures. The review and maintenance of procedures is a major burden. Elimination of proce- 
dures whenever possible is a good guideline. However, every critical action should be covered by proce- 
dures. Procedures should be written only when they are mandatory to insure adequate design. Procedures 
have a history of becoming bureaucratic, removing flexibility and stifling initiative. They are the means, 
not the end. Individual responsibility has been and will continue to be the fulcrum of good design and 
hardware. 

3. Validation 

Third, procedures must be tested and proved before implementation. They should also be as 
simple as possible to insure correctness. The range of activities that procedures cover is so large that it is 
hard to generalize. A manufacturing procedure is quite different from one for analysis. 

4. Involvement 

Fourth, all various parts or elements of a project should be involved at some level in develop- 
ment of procedures. Engineering, manufacturing, quality management, etc., should have inputs and 
reviews to insure adequacy and completeness. 
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5. Flexibility 

Fifth, procedures should have the flexibility to allow for evolving technology including analysis, 
materials, manufacturing, etc. Only with this flexibility can high performance be developed and validated 
for low margins, light weight, etc. 


B. Criteria 

Criteria, as well as procedures, determines the adequacy of the hardware. The design, its 
margins, and its sensitivity are governed by the criteria. Criteria covers every discipline, every phase, 
and every effort. Design, in general, is no better than the criteria. Areas requiring criteria are: (1) 
strength, (2) fracture mechanics, (3) fatigue, (4) structural stability, (5) dynamic and control stability, (6) 
deflections, (7) dynamic responses, (8) loads, (9) vibration and shock, (10) thermal, (11) acoustics, (12) 
testing, (13) fasteners, (14) inspections, (15) offsets, (16) control, (17) hydraulics, (18) electrical, (19) 
finish, (20) materials, (21) bonding, (22) flow (all natural environments), (23) manufacturing, (24) 
operations, etc. Criteria are always under strict control. Changes can only be made after detailed review 
and approval by all concerned, including PRCBs. If criteria are not met, then, in general, the design is 
not adequate by definition. If used as designed, then waivers must be approved by proper boards, etc. 

In the early space exploration days, all testing was prototype using dedicated, disposable 
hardware. In today’s world, the extra cost of building extra sets of hardware has opened up a new world 
called protoflight testing and/or verification by analysis, where hardware is flown after testing. This is a 
basic issue facing structural engineering since hardware cannot be tested to failure to determine limits. 
Verification becomes a combined analysis/test approach and raises new definitions of test procedures and 
criteria. This, coupled with time consistent probabilistic environments, opens up many new vistas of 
criteria, all of which must be considered and validated. The following areas of criteria must be con- 
sidered. 

1. Requirements 

High performance systems, because of the requirement for very accurate data, etc., drive toward 
a change in how criteria are developed and implemented. Instead of the conservative, additive, 
equivalent static margins, a probabilistic integrated approach is indicated. This not only means a change 
in how the structural data are generated, but also the criteria statement and how it is applied. Obviously, 
not all of the currently used criteria approaches are invalid. In fact, the opposite is true. Most are appli- 
cable as is or with modifications. What is argued here is an expansion of criteria approaches to include 
probabilistic approaches. The principle involved here is to open criteria up (flexibility) to incorporate 
currently developed probabilistic approaches required to design high performance, low margin, light 
weight structures. As with procedures, all disciplines and elements of the project must be involved in the 
development of criteria. One discipline may have the lead, but each must help in the development and 
control . 

2. Clarity 

Criteria must be clear, simple, definitive, etc. , so that no confusion or misunderstanding results in 
design and verification. Two extremes illustrate what the limitations for developing criteria and these 
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applications are. In the first extreme, a statement of the following character is made: “A safe, reliable 
system shall be designed and verified that meets a 3a probabilistic level of 95 percent confidence that 
includes all considerations of uncertainties such as environments, materials, analysis, test, manufactur- 
ing, etc.” This statement allows flexibility in methods, approaches, etc., used to meet this encompassing 
statement of criteria. The other extreme writes a very detailed set of criteria for each discipline somewhat 
independent of other disciplines. This approach tends toward a conservative design due to the inherent 
narrow look of each area leading to loss of flexibility, creativity, and innovation. Obviously, neither 
extreme is desirable, however, the balanced approach must take the system viewpoint and lean toward 
the first statement. There are many implications of taking this approach, including the contractural, 
legalistic one. These must also be considered in criteria development. 

3. Specifics 

Clearly, criteria must be specific in that it covers all hardware phases, preliminary design, design, 
verification, operations, refurbishment, and life management. Various approaches are apparent. For 
example, life management can be only a procedure/criteria for using hardware as verified versus up front 
impacting design with criteria that considers refurbishment, operations, maintenance, etc. As stated 
previously, the integrated look is mandatory versus a discrete look. 

4. Reviews/Updates 

Clearly with these same systems and approaches where nonlinear approaches are relied on, failure 
criteria needs further definition and quantification. Safety factors and related margins are arbitrary 
numbers, supposedly based on cost and success experiences, but really do not correlate to the safety of 
the component and system. All safety factors on failure and duration should be referenced to probability 
of failure. It would be more significant to estimate the weight, cost, life, or other performance to the 
probability of success, and the delta increase required to decrease the risk one more order of magnitude. 
The same is true for many exotic materials and composites. An example of the difficulty of developing 
criteria is the use of safety factors for nonlinear systems. As long as the system is linear dealing with 
loads, stress, and strain give the same results since everything is linear and correlated in this linear 
fashion (Fig. 49). If, however, the operating point is in the nonlinear portions of the curve stress, strain, 
and loads are related in a nonlinear manner. Notice that for points A and B, when the apparent stress is 
projected to the stress strain curve, the difference in apparent stress is substantial while the real stress 
changes very little and the strain is large. In the nonlinear portion of the curve, strain increases dramati- 
cally with increasing load while stress changes very little. The obvious question for this region becomes 
how do you write or derive the safety factor? Do you write it against loads, stress, or strain? Different 
numbers result if you do. Classically, safety factors have been developed for linear systems. Current high 
performance systems operate in or near the nonlinear range, opening up a redefinition for criteria. Other 
examples exist and must be dealt with in a rational manner to adequately verify structures. If safety factor 
is defined as loads relative to structure failure, then high strain exists with nominal stress (point A) (Fig. 
49). Employing nonlinear stress analysis will define the proper relationship between stress and strain 
while the linear analysis will produce the apparent stress. This makes it clear that real stresses and 
strains can be determined but keeps the safety factor criteria question open. Obviously, it is better to 
design a system where these effects are bypassed. For example, operating in the linear range gives a 
properly understood safety factor. Using linear analysis in a nonlinear range would predict failure where 
it did not occur and negative margins of safety. The nonlinear analysis predicts correct stress but can be 
misleading as to the sensitivity to failure. The principle is clear, continually review and update criteria 
commensurate with the materials usage and performance requirements. 
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STRAIN 

Figure 49. Typical stress strain relationship. 

As just discussed, the criteria for any space system (vehicle) is very large and all encompassing, 
going from natural and induced environments to operations. The scope of the documentation is too 
voluminous to reference or show. In the structures world, typical criteria includes safety factors, vibra- 
tion testing, proof testing, fracture mechanics, and environments. All of these have documents that cover 
all contingencies. Selected items from some of these have been chosen for illustration. 

Vibration testing of components to the expected level as a function of frequency and direction is 
conducted at three different levels, namely, developmental testing, qualification testing, and acceptance 
testing. No component is qualified until it passes qualification testing. New hardware is accepted only 
after passing acceptance testing designed to screen manufacturing flaws. Figure 50, taken from Refer- 
ence 41, defines the deviations allowed on the vibration spectra during testing. Criteria differs also 
whether one deals with prototype versus protoflight testing. Many other issues such as test time 
durations, levels, etc., are defined in the reference. 

Structural loads must consider known variations of all environments, models, etc., used to 
generate the responses. One example of criteria for the combined probabilities of these parameters for 
each launch phase is shown on Figure 51 (taken from Reference 22). 

Using the high confidence level limit loads, structural tests are run to verify structural margins. 
One example of design safety factors is shown in Figure 52, taken from Reference 22. Many other 
combinations and levels of safety factors exist for various verification approaches, hardware, etc. Proof 
testing of pressure vessels has many uses and values. Figure 53 shows typical criteria for various pressure 
vessel structures [33]. 

One final example of criteria is shown for fracture mechanics (Fig. 54) [24]. This is a flow chart 
from the MSFC fracture mechanics criteria showing the control and selection of fracture critical parts. 
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THE TEST SPECTRA SHALL BE VERIFIED BY NARROW BAND SPECTRAL ANALYSIS 
USING AN ANALYSIS SYSTEM THAT IS INDEPENDENT FROM THE ANALYZER/EQUALIZER 
USED TO CONTROL THE TEST. TOLERANCES CONSIDERED ACCEPTABLE AREAS FOLLOWS: 

•VIBRATION ±10% 

COMPOSITE ROOT MEAN SQUARE ACCELERATION 

ACCELERATION SPECTRAL DENSITY +1 00% 

(TOLERANCES PERTAIN TO BANDWIDTHS OF 25 Hz OR LESS) -30% 

SINUSOIDAL PEAK ACCELERATION +20% 

- 10 % 

SINUSOIDAL CONTROL SIGNAL MAXIMUM ±1 0% 

HARMONIC DISTORTION 

FREQUENCY ±5% 

TEST DURATION +10% 

- 0 % 

• SHOCK SPECTRUM 

SPECTRUM PEAK ACCELERATION +40% 

(WHEN ANALYZED WITH A 1/3 OCTAVE SHOCK SPECTRUM -20% 

ANALYZER AND 5% DAMPING) 

• SHOCK PULSE 

AMPLITUDE +40% 

- 20 % 

DURATION ±10% 


Figure 50. Vibration spectra tolerance. 



MISSION PHASE 


DEFINITION OF PROBABILITY VALUE 


LIMIT-LOAD 
PROBABILITY LEVEL 
(95% CONFIDENCE) 


PRELAUNCH PROBABILITY OF NOT HAVING TO RETURN A VEHICLE FROM THE PAD 99% 

TO THE ASSEMBLY AREA, OR TO IMPLEMENT SPECIAL TIE-DOWN 
PROCEDURES BECAUSE OF STRUCTURAL CAPABILITY LIMITATIONS 
WITH RESPECT TO THE PRELAUNCH GROUND ENVIRONMENT. 

LAUNCH PROBABILITY OF NQT HAVING TO DELAY A LAUNCH BECAUSE OF STRUCTURAL 99% 

CAPABILITY LIMITATIONS WITH RESPECT TO THE LAUNCH GROUND 
ENVIRONMENT. 

ASCENT PROBABILITY OF NQI HAVING TO DELAY A LAUNCH BECAUSE OF STRUCTURAL 95% 

CAPABILITY LIMITATIONS WITH RESPECT TO THE ANTICIPATED ASCENT 
ENVIRONMENT. 

SEPARATION PROBABILITY OF NQI HAVING TO ABORT A MISSION BECAUSE OF STRUCTURAL 99.9% 

CAPABILITY LIMITATIONS WITH RESPECT TO THE SEPARATION ENVIRONMENT. 

SPACE PROBABILITY OF NOT HAVING ABNORMAL SPACE OPERATIONS OF 99% 

STRUCTURAL CAPABILITY LIMITATIONS WITH RESPECT TO THE ASSOCIATED 
ENVIRONMENTS. 

ENTRY PROBABILITY OF NOT HAVING TO ALTER THE ENTRY FLIGHT PLAN BECAUSE OF 99% 

STRUCTURAL CAPABILITY LIMITATIONS ASSOCIATED WITH THE ANTICIPATED 
ENTRY ENVIRONMENT 

ATMOSPHERIC PROBABILITY OF NOT HAVING TO DELAY ENTRY OR NQI HAVING TO SELECT AN 99% 


FLIGHT ALTERNATE LANDING SITE BECAUSE OF STRUCTURAL CAPABILITY LIMITATIONS 

WITH RESPECT TO ANTICIPATED ATMOSPHERIC ENVIRONMENTS. 


Figure 51. Illustrative limit-load probabilities. 





COMPONENT 

FACTORS 

YIELD 

ULTIMATE 

PROOF 

GENERAL UNPRESSURIZED STRUCTURE 

>1.0 

1.5 

- 

WINDOWS, DOORS, AND HATCHES 


3.0 

2.0 

PRESSURIZED STRUCTURE** 

r > i.o 

M.5 

/ - 


l 

l 2.0 

11.5 

PRESSURIZED LINES AND FITTINGS 

— 

2.5 

1.5 

MAIN PROPELLANT TANK 

i.i 

1.4 

1.05 

PRESSURE VESSELS (OTHER THAN PROPELLANT TANKS) 

— 

2.0 

1.5 


** FOR PRESSURIZED STRUCTURE, BOTH ULTIMATE FACTORS OF SAFETY INDICATED SHOULD BE APPLIED 
AS FOLLOWS: 

1.5 x LIMIT LOAD +1.0 x LIMIT PRESSURE (i.e.,1.5 x LIMIT LOAD APPLIED AT LIMIT PRESSURE) 

AND 

0 x LIMIT LOAD +2.0 x LIMIT PRESSURE (i.e., 2.0 x LIMIT PRESSURE APPLIED AT ZERO LIMIT PRESSURE) 


Figure 52. Factors of safety. 
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Figure 53. The effect of wall thickness on value of proof test. 
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Figure 54. Fracture control selection and disposition of parts. 





These snapshots have shown only brief glances at criteria. In the aerospace world of manned 
flight, criteria and the validating documents required to verify that hardware has complied, constitute a 
major effort of structural design. Understanding of criteria and plans to incorporate it become key to 
adequate structural design. 


C. Summary 

It is not the purpose of this report to provide guidelines for developing or baselining procedures or 
criteria. Nor is it intended as a reference of all these documents, however, some typical ones are listed in 
the references. Also under documentation, a typical flow down was provided and is applicable uni- 
versally. As is evidenced by this and other listings, the process starts with requirements and the asso- 
ciated procedures and criteria and flows down into ICDs, specifications, OMIs,, OMRSDs, FMEA- 
CILs, hazards analyses, etc., necessary to verify that requirements have been met. 


VIII. SUMMARY 


The experience gained through audits and other exercises, coupled with past engineering 
expertise, have led to the formulation of lessons learned and general principles leading to adequate design 
and verification of structural systems as applied to space vehicles and space systems. This compilation is 
obviously not all inclusive nor complete but represents a partial listing of the conclusions reached by 
several involved in these activities. The interpretations are the author’s. Using these guidelines, design 
and verification of a space system should be improved; however, it is the nature of this business that 
problems will occur. In fact, it has been and will be that the preponderance of what we have learned 
comes because of the presence of problems. A summary listing of lessons learned is contained in the 
following. 


Lessons Learned 


A. Philosophy 

1. Validated design requires both top down (system) and bottom up (part) approaches 

a. Top Down 

(1) Discipline and component interaction emphasized 

(2) Focuses output 

b. Bottom Up 

(1) Drives detailed penetration at local levels, etc. 

(2) Emphasizes special disciplines. 
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2. Sensitivity of all parts of system to key parameters must be started initially and continued 
through program in order to focus efforts on key effects. Eliminates poor design. 

3. Robustness is the secret to good design and quality. Quality control (inspections) is for insurance 
and risk reduction. 

4. Design and manufacturing in quality do not depend on inspection. 

5. Plan initially for adequate development and verification instrumentation from part through flight 
testing. 

6. Clearly define failure philosophy up front (fail safe, fail operational-fail safe). 

7. Fracture mechanics and all special requirements must be incorporated as a design philosophy up 
front to insure adequate coverage. 

8. Design where practical for high (peak) stresses to occur in parent material instead of welds. 

9. Eliminate coupling (3-D effects), static and dynamic in design where possible. 

10. Design for margins linearly, test to prove it, inspect to verify, invoke nonlinearities for surprises. 

11. Derive criteria to force hardware to meet philosophy, requirements, objectives, etc. 

B. General 

1 . Performance requirements determine design and sensitivity to variations and must be thoroughly 
understood and worked to reduce risks, etc. The higher the performance requirements, the higher 
the sensitivity of the design. 

2. Innovative approaches in analysis, testing, and management are key to flexibility and accuracy. 

3. Models are just that, models, only as good as the assumptions used. 

a. All analyses are simulations which are not complete (limited), which attempt to predict trends 
and what will happen. Models are not exact representations of physical laws. 

b. Test (components, subsystems, systems, scale, etc.) only partially replicates real life situations. 
It is biased by the limited insight and provisions of the test engineer. 

c. How do you put these together to get a validated design is the major problem that must be 
addressed. 

4. Design breaks down with lack of coordination and definition of part/vehicle interface 
requirements, etc. 
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C. Management and Control 


1. The use of independent reviews/analyses, etc., is a prime means of eliminating errors. Several 
levels of reviews are available and should be used. 

a. Management overview/audits 

b. Independent check 

c. Independent analysis 

d. Independent codes 

Comprehensive reviews of results/approaches to insure discipline interaction and completeness are 
a fundamental part of these reviews. 

2. Communication between disciplines, etc., is mandatory. Management must insure that the 
openess, lines of communication, etc., are clearly emphasized and implemented. 

3. Methodology, procedures, criteria, etc., must be under essentially constant review to insure 
applicability of assumptions, etc., and adequate design. 

4. People are the prime resource, all other resources are aids to the human. The individual accept- 
ance of the responsibility of the tasks and to growth, communication, and planning is the key to 
success. Managements’ emphasis on people must be the first priority. 

5. Requirements up front for flight certification, overhaul, life extension, etc., are mandatory as a 
management tool for control to insure correct design. 

6. Proper determination and manning of skills is essential from program start to finish. Do not allow 
reduction as cost savings, etc. 

7. Management must assure that proper interface symbols, etc. exist and flow vertically and horizon- 
tally. 

8. Prioritization of tasks toward results, both long range and immediate, is a prime task. 

D. Analysis and Test 

1 . Methodology is one of the keys to accuracy providing: 

a. Flexibility 

b. Usability 

c. Adaptability 
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and must match what is expected from analysis, requires periodic review for validity, is 
implemented through structural manuals, procedures, handbooks, etc., and must cover all areas 
such as: 

(1) Loads combination 

(2) Fatigue 

(3) Fracture mechanics 

(4) Modeling 

(5) Environments 

2. Analysis is only as good as the development and validation testing. Required are: 

a. Pretest predictions, procedures, requirements, instrumentation 

b. Test analysis correlation 

c. Analysis update based on test. 

3. Validation of margins requires the establishment of as-built data bases on key structures, etc. 
Typical parameters are: 

a. Weld offsets 

b. Weld Kq’s 

c. Misalignments 

d. Flaws. 

4. Data bases maintained, communicated, and controlled are key to analysis validity (automated 
preferred). Examples: 

a. Materials properties 

b. Vibration 

c. Internal fluid flow 

d. Environments, natural and induced 

e. Margins, durability, etc. 
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5. The engineer’s choice of codes, elements, assumptions, etc., determines output validity. The 
other side of this coin is validity of input data. Codes, etc., cannot be used indiscriminately. 
Involved are: 

a. Element choices 

b. Linear versus nonlinear 

c. Compatibility between elements and environments, etc. 

6. Materials characterization is the single most important item in durability. It must match details 
and assumptions of models. 

7. Sensitivity analysis is key to understanding system and bracketing limitations. 

8. Updating analysis, etc., as design changes, computational/methodology improves, etc., must be 
a continuous activity. 

9. Statistical significance of results is necessary for proper interpretation. 

10. Well defined and implemented structural test programs are a validation must. 

11. Development testing, component and system, is required to properly determine environments. 

12. Efficiency and accuracy can be improved through use of: 

a. Stress and loads transformations 

b. Automated screening 

c. Load indications 

d. Statistical significance 

e. Graphing and displays. 

13. Input environments accuracy as a function of response sensitivity is one key to cost effective 
design. 

14. System approaches are required for understanding and validation. 

15. Compatibility must exist between all models, environments, etc. 

16. Analysis technologies must match the analysis/performance requirements. Examples: 

a. Combination of low cycle frequency and high cycle frequency 

b. Low and high cycle fracture mechanics 
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c. Plastic fracture mechanics 


d. Nonlinear (local) yielding 

17. Current problems in analysis/test (short-comings) 

a. Data to support Goodman’s diagrams 

b. Failure criteria for ductile material 

c. Bolts/fasteners/threads 

d. 3-D effect on fatigue 

e. Combination low cycle frequency and high cycle frequency 

f. Accumulated linear damage rules 

g. Nonlinear fracture mechanics 

h. Techniques for residual stresses 

i. Analysis and test turnaround time much too long for proper program impact. Example: 1 year 
cycle for system loads analysis. 

18. Integrated analysis/optimized design from overall viewpoint increases understanding, 
efficiency, and margins. 

E. Documentation and Data Basing 

1 . Documentation is a must and requires clear statements of assumptions, data, etc. , including trace- 
ability identification. 

2. Lack of traceability of documentation is a major problem in validation. 

3. Documentation must occur at all levels, have various levels of control, and include as a minimum: 

a. Requirements 

b. ICD’s (interface control documents) 

c. Procedures 

d. Methodology 

e. Plans and schedules 
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f. Analysis and test results 

g. Criteria 

h. Specifications 

i. Drawings 

j. Manufacturing and quality records, etc. 

k. Photographs and films. 

4. Documentation should be located in a central place or have clearly defined area of where it is. 
Working papers in someone’s desk are not sufficient. 

5. It is very helpful for traceability to have top level breakouts of document by disciplines and 
categories so that a quick determination can be made of what document to search for. 

6. Automated data basing is a must for current high performance systems cutting across many areas 
such as: 

a. Vibration 

b. Environments 

c. Material properties 

d. Life specifications 

e. Special analyses 

f. Test data 

g. Hardware usage. 

7. Adequate life management and refurbishment requires continuous use of these automated data 
bases. 

8. Data bases must have control procedures established to insure fidelity but must be accessible to 
users. 

F. Procedures and Criteria 

1 . Procedures/criteria/philosophy are the backbone of design and verification. They should contain: 
a. Criteria definition 
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b. Handbooks required, etc. 


c. Procedures and guidelines (standardization of approaches) 

d. Interaction/sequencing or flow 

e. Communication lines 

f. Working groups/boards/panels, etc. 

g. Control/management. 

2. Analysis and test procedures should not be so restrictive as to kill innovation, improvements, and 
special applications, but should define minimum type approaches, standard methods, etc. 
Handbooks fall into the same category. 

3. Criteria should be clear and definitive, spelling out boundaries, exceptions, etc. In general, 
criteria are very strict legal requirements. 

4. Criteria and procedures should be under continuous revision to insure applicability and adequacy. 

5. Procedures applied indiscriminately can result in erroneous data. 

6. Establishment of life management criteria is the secret to safe hardware operations. 

7. Criteria should be developed for all areas including manufacturing and quality. For example, weld 
offsets are not always specified, creating hardware lifetime problems. 
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